chore: import upstream snapshot with attribution
This commit is contained in:
wehub-resource-sync
@@ -0,0 +1,455 @@
|
||||
---
|
||||
allowed-tools: Bash(git:*), Read, Edit, Write
|
||||
argument-hint: <hotfix-name>
|
||||
description: Create a new Git Flow hotfix branch from main for emergency production fixes
|
||||
---
|
||||
|
||||
# Git Flow Hotfix Branch
|
||||
|
||||
Create emergency hotfix branch: **$ARGUMENTS**
|
||||
|
||||
## Current Repository State
|
||||
|
||||
- Current branch: !`git branch --show-current`
|
||||
- Git status: !`git status --porcelain`
|
||||
- Latest production tag: !`git describe --tags --abbrev=0 origin/main 2>/dev/null || echo "No tags on main"`
|
||||
- Main branch status: !`git log main..origin/main --oneline 2>/dev/null | head -3 || echo "No remote tracking for main"`
|
||||
- Commits on main since last tag: !`git log $(git describe --tags --abbrev=0 origin/main 2>/dev/null)..origin/main --oneline 2>/dev/null | wc -l | tr -d ' '`
|
||||
|
||||
## Task
|
||||
|
||||
Create a Git Flow hotfix branch for emergency production fixes:
|
||||
|
||||
### 1. Pre-Flight Validation
|
||||
|
||||
**Critical Checks:**
|
||||
- **Verify hotfix name**: Ensure `$ARGUMENTS` is provided and descriptive
|
||||
- ✅ Valid: `critical-security-patch`, `payment-gateway-fix`, `auth-bypass-fix`
|
||||
- ❌ Invalid: `fix`, `hotfix1`, `bug`
|
||||
- **Check main branch exists**: Ensure `main` branch is present
|
||||
- **Verify no uncommitted changes**: Clean working directory required
|
||||
- **Confirm emergency status**: Hotfixes are for CRITICAL production issues only
|
||||
|
||||
**⚠️ IMPORTANT: Hotfix Usage Guidelines**
|
||||
|
||||
Hotfixes are ONLY for:
|
||||
- 🔒 Critical security vulnerabilities
|
||||
- 💥 Production-breaking bugs
|
||||
- 💰 Payment/transaction failures
|
||||
- 🚨 Data loss or corruption issues
|
||||
- 🔥 System downtime or crashes
|
||||
|
||||
NOT for:
|
||||
- ❌ Regular bug fixes (use feature branch)
|
||||
- ❌ New features (use feature branch)
|
||||
- ❌ Performance improvements (use feature branch)
|
||||
- ❌ Non-critical issues (wait for next release)
|
||||
|
||||
### 2. Create Hotfix Branch Workflow
|
||||
|
||||
```bash
|
||||
# Switch to main branch
|
||||
git checkout main
|
||||
|
||||
# Pull latest production code
|
||||
git pull origin main
|
||||
|
||||
# Create hotfix branch from main
|
||||
git checkout -b hotfix/$ARGUMENTS
|
||||
|
||||
# Set up remote tracking
|
||||
git push -u origin hotfix/$ARGUMENTS
|
||||
```
|
||||
|
||||
### 3. Determine Version Bump
|
||||
|
||||
Analyze the latest tag to suggest hotfix version:
|
||||
|
||||
```
|
||||
Current production version: v1.2.0
|
||||
Hotfix version: v1.2.1
|
||||
|
||||
Version bump: PATCH (third number incremented)
|
||||
```
|
||||
|
||||
**Hotfix Version Rules:**
|
||||
- Always increment PATCH version (X.Y.Z → X.Y.Z+1)
|
||||
- Never increment MAJOR or MINOR for hotfixes
|
||||
- Examples:
|
||||
- v1.2.0 → v1.2.1
|
||||
- v2.0.5 → v2.0.6
|
||||
- v1.5.9 → v1.5.10
|
||||
|
||||
### 4. Success Response
|
||||
|
||||
```
|
||||
✓ Switched to main branch
|
||||
✓ Pulled latest production code from origin/main
|
||||
✓ Created branch: hotfix/$ARGUMENTS
|
||||
✓ Set up remote tracking: origin/hotfix/$ARGUMENTS
|
||||
✓ Pushed branch to remote
|
||||
|
||||
🔥 Hotfix Branch Ready: hotfix/$ARGUMENTS
|
||||
|
||||
Branch: hotfix/$ARGUMENTS
|
||||
Base: main (production)
|
||||
Will merge to: main AND develop
|
||||
Suggested version: v1.2.1
|
||||
|
||||
⚠️ CRITICAL HOTFIX WORKFLOW
|
||||
|
||||
This is an EMERGENCY production fix. Follow these steps:
|
||||
|
||||
1. 🔍 Identify the Issue
|
||||
- Reproduce the bug
|
||||
- Understand the root cause
|
||||
- Document the impact
|
||||
|
||||
2. 🛠️ Implement the Fix
|
||||
- Make MINIMAL changes
|
||||
- Focus ONLY on the critical issue
|
||||
- Avoid refactoring or improvements
|
||||
- Add tests to prevent regression
|
||||
|
||||
3. 🧪 Test Thoroughly
|
||||
- Test the specific fix
|
||||
- Run full regression tests
|
||||
- Test on production-like environment
|
||||
- Verify no side effects
|
||||
|
||||
4. 📝 Document the Fix
|
||||
- Update version in package.json
|
||||
- Add entry to CHANGELOG.md
|
||||
- Document the bug and fix
|
||||
- Include reproduction steps
|
||||
|
||||
5. 🚀 Deploy Process
|
||||
- Create PR to main
|
||||
- Get expedited review
|
||||
- Run /finish to merge and tag
|
||||
- Deploy to production immediately
|
||||
- Monitor for issues
|
||||
|
||||
🎯 Next Steps:
|
||||
1. Fix the critical issue (MINIMAL changes only)
|
||||
2. Test thoroughly: npm test
|
||||
3. Update version: v1.2.1
|
||||
4. Create emergency PR: gh pr create --label "hotfix,critical"
|
||||
5. Get fast-track approval
|
||||
6. Run /finish to merge to main AND develop
|
||||
7. Deploy to production
|
||||
8. Monitor systems closely
|
||||
|
||||
⚠️ Remember:
|
||||
- Hotfix will be merged to BOTH main and develop
|
||||
- Tag v1.2.1 will be created on main
|
||||
- Production deployment should happen immediately
|
||||
- Team should be notified of the hotfix
|
||||
```
|
||||
|
||||
### 5. Error Handling
|
||||
|
||||
**No Hotfix Name Provided:**
|
||||
```
|
||||
❌ Hotfix name is required
|
||||
|
||||
Usage: /hotfix <hotfix-name>
|
||||
|
||||
Examples:
|
||||
/hotfix critical-security-patch
|
||||
/hotfix payment-processing-failure
|
||||
/hotfix auth-bypass-vulnerability
|
||||
|
||||
⚠️ IMPORTANT: Hotfixes are for CRITICAL production issues only!
|
||||
|
||||
For non-critical fixes, use:
|
||||
/feature <name> - Regular bug fixes
|
||||
```
|
||||
|
||||
**Invalid Hotfix Name:**
|
||||
```
|
||||
❌ Invalid hotfix name: "fix"
|
||||
|
||||
Hotfix names should be:
|
||||
- Descriptive of the issue
|
||||
- Use kebab-case format
|
||||
- Indicate severity/urgency
|
||||
|
||||
Examples:
|
||||
✅ critical-security-patch
|
||||
✅ payment-gateway-timeout
|
||||
✅ user-data-corruption-fix
|
||||
❌ fix
|
||||
❌ bug1
|
||||
❌ hotfix
|
||||
```
|
||||
|
||||
**Uncommitted Changes:**
|
||||
```
|
||||
⚠️ Uncommitted changes detected in working directory:
|
||||
M src/file.js
|
||||
A test.js
|
||||
|
||||
Hotfixes require a clean working directory.
|
||||
|
||||
Options:
|
||||
1. Commit your changes first
|
||||
2. Stash them: git stash
|
||||
3. Discard them: git checkout .
|
||||
|
||||
⚠️ This is an emergency hotfix. Please clean your working directory.
|
||||
```
|
||||
|
||||
**Main Branch Behind Remote:**
|
||||
```
|
||||
⚠️ Local main is behind origin/main by 2 commits
|
||||
|
||||
✓ Pulling latest production code...
|
||||
✓ Fetched 2 commits
|
||||
✓ Main is now synchronized with production
|
||||
✓ Ready to create hotfix branch
|
||||
```
|
||||
|
||||
**Not a Critical Issue:**
|
||||
```
|
||||
⚠️ Hotfix Confirmation Required
|
||||
|
||||
Is this a CRITICAL production issue that requires immediate attention?
|
||||
|
||||
Critical issues include:
|
||||
- Security vulnerabilities
|
||||
- Production system failures
|
||||
- Data loss or corruption
|
||||
- Payment/transaction failures
|
||||
|
||||
If this is NOT critical, consider:
|
||||
- Creating a feature branch instead
|
||||
- Waiting for the next release cycle
|
||||
- Using regular bug fix workflow
|
||||
|
||||
Proceed with hotfix? [y/N]
|
||||
```
|
||||
|
||||
### 6. Hotfix Checklist
|
||||
|
||||
```
|
||||
🔥 Emergency Hotfix Checklist
|
||||
|
||||
Issue Identification:
|
||||
- [ ] Bug is confirmed and reproducible
|
||||
- [ ] Root cause is identified
|
||||
- [ ] Impact is documented
|
||||
- [ ] Stakeholders are notified
|
||||
|
||||
Development:
|
||||
- [ ] Fix is minimal and focused
|
||||
- [ ] No unnecessary changes included
|
||||
- [ ] Tests added to prevent regression
|
||||
- [ ] Code reviewed (if time permits)
|
||||
|
||||
Testing:
|
||||
- [ ] Fix verified in local environment
|
||||
- [ ] Unit tests passing
|
||||
- [ ] Integration tests passing
|
||||
- [ ] Tested on production-like environment
|
||||
- [ ] No side effects detected
|
||||
|
||||
Documentation:
|
||||
- [ ] CHANGELOG.md updated
|
||||
- [ ] Version bumped (PATCH)
|
||||
- [ ] Bug description documented
|
||||
- [ ] Fix explanation documented
|
||||
- [ ] Deployment notes prepared
|
||||
|
||||
Deployment:
|
||||
- [ ] PR created with "hotfix" and "critical" labels
|
||||
- [ ] Fast-track approval obtained
|
||||
- [ ] Production deployment plan ready
|
||||
- [ ] Rollback plan documented
|
||||
- [ ] Monitoring alerts configured
|
||||
- [ ] Team notified of deployment
|
||||
|
||||
Post-Deployment:
|
||||
- [ ] Fix verified in production
|
||||
- [ ] Systems monitored for issues
|
||||
- [ ] Metrics show improvement
|
||||
- [ ] Hotfix merged back to develop
|
||||
- [ ] Post-mortem scheduled (if needed)
|
||||
```
|
||||
|
||||
### 7. Version Update Process
|
||||
|
||||
After implementing the fix, update the version:
|
||||
|
||||
```bash
|
||||
# Update package.json version (PATCH bump)
|
||||
npm version patch --no-git-tag-version
|
||||
|
||||
# Update CHANGELOG.md
|
||||
cat >> CHANGELOG.md << EOF
|
||||
|
||||
## [v1.2.1] - $(date +%Y-%m-%d) - HOTFIX
|
||||
|
||||
### 🔥 Critical Fixes
|
||||
- Fix $ARGUMENTS: [brief description]
|
||||
- Root cause: [explanation]
|
||||
- Impact: [who/what was affected]
|
||||
- Resolution: [what was fixed]
|
||||
|
||||
EOF
|
||||
|
||||
# Commit version bump
|
||||
git add package.json CHANGELOG.md
|
||||
git commit -m "chore(hotfix): bump version to v1.2.1
|
||||
|
||||
Critical fix for $ARGUMENTS
|
||||
|
||||
🤖 Generated with Claude Code
|
||||
Co-Authored-By: Claude <noreply@anthropic.com>"
|
||||
```
|
||||
|
||||
### 8. Create Emergency PR
|
||||
|
||||
```bash
|
||||
gh pr create \
|
||||
--title "🔥 HOTFIX v1.2.1: $ARGUMENTS" \
|
||||
--body "$(cat <<'EOF'
|
||||
## 🔥 Emergency Hotfix
|
||||
|
||||
**Severity**: Critical
|
||||
**Version**: v1.2.1
|
||||
**Issue**: $ARGUMENTS
|
||||
|
||||
## Problem Description
|
||||
|
||||
[Detailed description of the production issue]
|
||||
|
||||
## Root Cause
|
||||
|
||||
[Explanation of what caused the issue]
|
||||
|
||||
## Fix Implementation
|
||||
|
||||
[Description of the fix applied]
|
||||
|
||||
## Testing
|
||||
|
||||
- [x] Issue reproduced locally
|
||||
- [x] Fix verified locally
|
||||
- [x] Unit tests passing
|
||||
- [x] Integration tests passing
|
||||
- [x] Tested on staging environment
|
||||
|
||||
## Deployment Plan
|
||||
|
||||
1. Merge to main
|
||||
2. Tag as v1.2.1
|
||||
3. Deploy to production immediately
|
||||
4. Monitor for 30 minutes
|
||||
5. Merge back to develop
|
||||
|
||||
## Rollback Plan
|
||||
|
||||
[How to rollback if issues occur]
|
||||
|
||||
## Monitoring
|
||||
|
||||
[What to monitor post-deployment]
|
||||
|
||||
---
|
||||
|
||||
**⚠️ This is a critical production hotfix requiring immediate deployment**
|
||||
|
||||
🤖 Generated with Claude Code
|
||||
EOF
|
||||
)" \
|
||||
--base main \
|
||||
--head hotfix/$ARGUMENTS \
|
||||
--label "hotfix,critical,priority-high" \
|
||||
--assignee @me \
|
||||
--reviewer team-leads
|
||||
```
|
||||
|
||||
## Git Flow Integration
|
||||
|
||||
**Hotfix Workflow in Git Flow:**
|
||||
|
||||
```
|
||||
main (v1.2.0) ──────┬─────────────► (after hotfix merge) v1.2.1
|
||||
│
|
||||
└─► hotfix/$ARGUMENTS
|
||||
│
|
||||
└─► (merges back to both)
|
||||
│
|
||||
develop ────────────────────┴─────────────► (receives hotfix)
|
||||
```
|
||||
|
||||
**Important:**
|
||||
- Hotfixes branch from `main` (production)
|
||||
- Hotfixes merge to BOTH `main` AND `develop`
|
||||
- Tags are created on `main` after merge
|
||||
- Production deployment happens immediately
|
||||
|
||||
## Environment Variables
|
||||
|
||||
- `GIT_FLOW_MAIN_BRANCH`: Main branch name (default: "main")
|
||||
- `GIT_FLOW_DEVELOP_BRANCH`: Develop branch name (default: "develop")
|
||||
- `GIT_FLOW_PREFIX_HOTFIX`: Hotfix prefix (default: "hotfix/")
|
||||
|
||||
## Related Commands
|
||||
|
||||
- `/finish` - Complete hotfix (merge to main and develop, create tag, deploy)
|
||||
- `/flow-status` - Check current Git Flow status
|
||||
- `/feature <name>` - Create feature branch (for non-critical fixes)
|
||||
- `/release <version>` - Create release branch
|
||||
|
||||
## Best Practices
|
||||
|
||||
**DO:**
|
||||
- ✅ Use hotfixes ONLY for critical production issues
|
||||
- ✅ Keep changes minimal and focused
|
||||
- ✅ Test thoroughly before deploying
|
||||
- ✅ Document the issue and fix clearly
|
||||
- ✅ Notify team immediately
|
||||
- ✅ Merge back to develop after production deployment
|
||||
- ✅ Monitor production closely after deployment
|
||||
- ✅ Conduct post-mortem if appropriate
|
||||
|
||||
**DON'T:**
|
||||
- ❌ Use hotfix for regular bug fixes
|
||||
- ❌ Add new features to hotfix
|
||||
- ❌ Refactor code during hotfix
|
||||
- ❌ Skip testing to save time
|
||||
- ❌ Forget to merge back to develop
|
||||
- ❌ Deploy without proper review
|
||||
- ❌ Skip documentation
|
||||
- ❌ Ignore monitoring after deployment
|
||||
|
||||
## Post-Hotfix Actions
|
||||
|
||||
After successful hotfix deployment:
|
||||
|
||||
1. **Verify Fix in Production**
|
||||
- Monitor error rates
|
||||
- Check affected functionality
|
||||
- Verify metrics return to normal
|
||||
|
||||
2. **Update Documentation**
|
||||
- Document the incident
|
||||
- Update runbooks if needed
|
||||
- Share learnings with team
|
||||
|
||||
3. **Merge to Develop**
|
||||
- Ensure hotfix is in develop branch
|
||||
- Resolve any merge conflicts
|
||||
- Push to remote
|
||||
|
||||
4. **Post-Mortem (if needed)**
|
||||
- Schedule review meeting
|
||||
- Identify prevention measures
|
||||
- Update processes if needed
|
||||
|
||||
5. **Cleanup**
|
||||
- Delete hotfix branch
|
||||
- Archive related documentation
|
||||
- Update incident tracking
|
||||
Reference in New Issue
Block a user