Git Workflow Strategies for Teams

Choosing the right Git workflow can significantly impact your team's productivity and code quality. Let's explore the most popular strategies and when to use each.

Git Flow

Git Flow is a structured branching model ideal for projects with scheduled releases.

Branch Structure

text
main (production)
├── develop (integration)
│   ├── feature/user-auth
│   ├── feature/payment-system
│   └── feature/notifications
├── release/v1.2.0
└── hotfix/critical-bug

Key Commands

bash
# Start a feature
git checkout develop
git checkout -b feature/user-auth

# Complete a feature
git checkout develop
git merge --no-ff feature/user-auth
git branch -d feature/user-auth

# Start a release
git checkout develop
git checkout -b release/v1.2.0

# Complete a release
git checkout main
git merge --no-ff release/v1.2.0
git tag -a v1.2.0 -m "Release v1.2.0"
git checkout develop
git merge --no-ff release/v1.2.0

# Hotfix
git checkout main
git checkout -b hotfix/critical-bug
# Fix the bug
git checkout main
git merge --no-ff hotfix/critical-bug
git tag -a v1.2.1 -m "Hotfix v1.2.1"
git checkout develop
git merge --no-ff hotfix/critical-bug

When to Use Git Flow

• Products with scheduled release cycles
• Multiple versions in production
• Formal QA/staging environments
• Teams with dedicated release managers

GitHub Flow

A simpler workflow centered around pull requests.

The Process

1. Create a branch from main
2. Add commits
3. Open a pull request
4. Discuss and review
5. Deploy and test
6. Merge to main

bash
# Start work
git checkout main
git pull origin main
git checkout -b add-user-search

# Make changes and commit
git add .
git commit -m "Add user search functionality"

# Push and create PR
git push -u origin add-user-search
# Create PR on GitHub

# After approval and CI passes
# Merge via GitHub UI or:
git checkout main
git merge add-user-search
git push origin main

When to Use GitHub Flow

• Continuous deployment
• Web applications
• Small to medium teams
• Projects with single production version

Trunk-Based Development

Everyone commits to a single branch (trunk/main) with short-lived feature branches.

Key Principles

bash
# Pull latest
git checkout main
git pull --rebase origin main

# Create short-lived branch (optional)
git checkout -b feature/quick-fix

# Make small, incremental changes
git add .
git commit -m "Add input validation for email"

# Merge quickly (same day ideally)
git checkout main
git pull --rebase origin main
git merge feature/quick-fix
git push origin main

Feature Flags

With trunk-based development, incomplete features are hidden behind flags:

javascript
// Feature flag implementation
const features = {
  newDashboard: process.env.FEATURE_NEW_DASHBOARD === 'true',
  betaPayments: process.env.FEATURE_BETA_PAYMENTS === 'true'
};

function renderDashboard() {
  if (features.newDashboard) {
    return <NewDashboard />;
  }
  return <LegacyDashboard />;
}

When to Use Trunk-Based

• Mature CI/CD pipelines
• Strong testing culture
• Experienced developers
• Need for very fast iteration

Forking Workflow

Used primarily in open-source projects where contributors don't have write access.

bash
# Fork repository on GitHub

# Clone your fork
git clone git@github.com:yourusername/project.git
cd project

# Add upstream remote
git remote add upstream git@github.com:original/project.git

# Create feature branch
git checkout -b fix-typo

# Make changes and commit
git add .
git commit -m "Fix typo in README"

# Push to your fork
git push origin fix-typo

# Create PR from your fork to upstream

# Keep fork updated
git fetch upstream
git checkout main
git merge upstream/main
git push origin main

Commit Message Conventions

Conventional Commits

text
<type>(<scope>): <description>

[optional body]

[optional footer]

Types:

• feat: New feature
• fix: Bug fix
• docs: Documentation
• style: Formatting
• refactor: Code restructuring
• test: Adding tests
• chore: Maintenance

Examples:

text
feat(auth): add OAuth2 login support

Implements Google and GitHub OAuth providers.
Closes #123

BREAKING CHANGE: removes legacy session-based auth

Pull Request Best Practices

PR Template

markdown
## Description
Brief description of changes

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update

## Testing
- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] Manual testing completed

## Checklist
- [ ] Code follows style guidelines
- [ ] Self-reviewed code
- [ ] Commented complex logic
- [ ] Updated documentation

Code Review Guidelines

1. Review promptly: Don't block teammates
2. Be constructive: Suggest improvements, don't criticize
3. Focus on important issues: Don't nitpick style
4. Ask questions: If something is unclear
5. Approve when good enough: Perfect is the enemy of good

Choosing the Right Workflow

Conclusion

There's no universally "best" workflow. GitHub Flow works well for most web applications with continuous deployment. Git Flow suits projects with formal releases. Trunk-based development is excellent for experienced teams with robust testing. Choose based on your team's needs and adapt as you grow.