112 lines
2.7 KiB
Plaintext
112 lines
2.7 KiB
Plaintext
---
|
|
alwaysApply: true
|
|
---
|
|
|
|
# Git Feature Branch Workflow
|
|
|
|
## Always Work in Feature Branches
|
|
|
|
**CRITICAL**: Never work directly on `main` or `master` branches. Always create and use feature branches for all development work.
|
|
|
|
## Feature Branch Naming Convention
|
|
|
|
Use descriptive, kebab-case names for feature branches:
|
|
- `feature/user-authentication`
|
|
- `feature/dashboard-redesign`
|
|
- `bugfix/login-validation`
|
|
- `hotfix/security-patch`
|
|
- `refactor/api-endpoints`
|
|
|
|
## Workflow Steps
|
|
|
|
### 1. Before Starting Work
|
|
```bash
|
|
# Ensure you're on main and it's up to date
|
|
git checkout main
|
|
git pull origin main
|
|
|
|
# Create and switch to a new feature branch
|
|
git checkout -b feature/your-feature-name
|
|
```
|
|
|
|
### 2. During Development
|
|
- Make frequent, small commits with descriptive messages
|
|
- Use conventional commit format: `type(scope): description`
|
|
- Examples:
|
|
- `feat(auth): add login form validation`
|
|
- `fix(ui): resolve button alignment issue`
|
|
- `refactor(api): simplify user data fetching`
|
|
|
|
### 3. Before Pushing
|
|
```bash
|
|
# Ensure your branch is up to date with main
|
|
git fetch origin
|
|
git rebase origin/main
|
|
|
|
# Push your feature branch
|
|
git push origin feature/your-feature-name
|
|
```
|
|
|
|
### 4. Code Review Process
|
|
- Create a Pull Request (PR) from your feature branch to main
|
|
- Request reviews from team members
|
|
- Address feedback and push updates to the same branch
|
|
- Only merge after approval
|
|
|
|
### 5. After Merge
|
|
```bash
|
|
# Switch back to main and update
|
|
git checkout main
|
|
git pull origin main
|
|
|
|
# Delete the feature branch (local and remote)
|
|
git branch -d feature/your-feature-name
|
|
git push origin --delete feature/your-feature-name
|
|
```
|
|
|
|
## Best Practices
|
|
|
|
### Commit Messages
|
|
- Use present tense ("add feature" not "added feature")
|
|
- Be specific and descriptive
|
|
- Reference issue numbers when applicable: `feat(auth): add OAuth login #123`
|
|
|
|
### Branch Management
|
|
- Keep feature branches short-lived (1-3 days ideally)
|
|
- One feature per branch
|
|
- Don't mix different types of changes in one branch
|
|
|
|
### Before Creating PRs
|
|
- Ensure all tests pass
|
|
- Update documentation if needed
|
|
- Self-review your changes
|
|
- Ensure code follows project conventions
|
|
|
|
## Emergency Hotfixes
|
|
|
|
For critical production issues:
|
|
```bash
|
|
# Create hotfix branch from main
|
|
git checkout main
|
|
git checkout -b hotfix/critical-issue-name
|
|
|
|
# Make minimal necessary changes
|
|
# Test thoroughly
|
|
# Create PR for immediate review
|
|
```
|
|
|
|
## Integration with CI/CD
|
|
|
|
- Feature branches should trigger CI/CD pipelines
|
|
- All tests must pass before merging
|
|
- Code coverage should not decrease
|
|
- Security scans should pass
|
|
|
|
## Remember
|
|
|
|
- **Never commit directly to main/master**
|
|
- **Always create a feature branch for new work**
|
|
- **Keep branches focused and small**
|
|
- **Use descriptive branch and commit names**
|
|
- **Review your own code before requesting reviews**
|