Git Workflow Strategies for Development Teams

The right Git workflow keeps your team productive and your codebase stable. Here's how to choose and implement the workflow that fits your team.

Git Flow#

Structure#

main (production)
  └── develop (integration)
        ├── feature/user-auth
        ├── feature/payment-system
        └── feature/dashboard

release/1.0
  └── (branches from develop, merges to main and develop)

hotfix/critical-bug
  └── (branches from main, merges to main and develop)

Commands#

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

# Work on feature
git add .
git commit -m "Add user authentication"

# Finish 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/1.0

# Finish release
git checkout main
git merge --no-ff release/1.0
git tag -a v1.0.0 -m "Version 1.0.0"
git checkout develop
git merge --no-ff release/1.0
git branch -d release/1.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.0.1 -m "Hotfix 1.0.1"
git checkout develop
git merge --no-ff hotfix/critical-bug
git branch -d hotfix/critical-bug

When to Use#

Good for:
✓ Scheduled releases
✓ Multiple versions in production
✓ Strict release management
✓ Large teams with defined roles

Not ideal for:
✗ Continuous deployment
✗ Small, agile teams
✗ Simple projects

GitHub Flow#

Structure#

main (always deployable)
  ├── feature/add-search
  ├── fix/login-bug
  └── update/dependencies

Process#

# 1. Create branch from main
git checkout main
git pull origin main
git checkout -b feature/add-search

# 2. Make changes and commit
git add .
git commit -m "Add search functionality"
git push -u origin feature/add-search

# 3. Open Pull Request on GitHub
# - Request reviews
# - Run CI/CD checks
# - Discuss changes

# 4. Deploy to staging (optional)
# - Test in production-like environment

# 5. Merge to main
# - Squash or merge commit
# - Delete branch

# 6. Deploy to production
# - Automated after merge

When to Use#

Good for:
✓ Continuous deployment
✓ Simple release process
✓ Small to medium teams
✓ Web applications

Not ideal for:
✗ Multiple production versions
✗ Long release cycles
✗ Complex release management

Trunk-Based Development#

Structure#

main (trunk)
  ├── short-lived-branch-1 (< 1 day)
  ├── short-lived-branch-2 (< 1 day)
  └── (direct commits for small changes)

Process#

# Small changes: commit directly
git checkout main
git pull origin main
# Make small change
git add .
git commit -m "Fix typo in header"
git push origin main

# Larger changes: short-lived branch
git checkout main
git pull origin main
git checkout -b add-button
# Work for a few hours max
git add .
git commit -m "Add submit button to form"
git checkout main
git pull origin main
git merge add-button
git push origin main
git branch -d add-button

Feature Flags#

// Use feature flags for incomplete features
const features = {
  newCheckout: process.env.ENABLE_NEW_CHECKOUT === 'true',
  darkMode: process.env.ENABLE_DARK_MODE === 'true',
};

function CheckoutPage() {
  if (features.newCheckout) {
    return <NewCheckout />;
  }
  return <OldCheckout />;
}

When to Use#

Good for:
✓ Continuous integration
✓ High-performing teams
✓ Rapid iteration
✓ Teams with strong testing

Not ideal for:
✗ Teams without CI/CD
✗ Inexperienced developers
✗ Complex feature work

Branch Naming Conventions#

# Feature branches
feature/user-authentication
feature/JIRA-123-add-search
feat/payment-integration

# Bug fixes
fix/login-redirect
bugfix/null-pointer
hotfix/security-patch

# Other types
docs/update-readme
refactor/extract-user-service
test/add-integration-tests
chore/update-dependencies

Commit Message Conventions#

# Conventional Commits
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

# Types
feat:     New feature
fix:      Bug fix
docs:     Documentation
style:    Formatting (no code change)
refactor: Code restructuring
test:     Adding tests
chore:    Maintenance

# Examples
feat(auth): add password reset functionality

fix(api): handle null response from payment gateway

Closes #123

docs: update API documentation for v2 endpoints

refactor(user): extract validation into separate module

BREAKING CHANGE: User.validate() now returns a Result type

Pull Request Best Practices#

## PR Template

### Description
Brief description of what this PR does.

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

### How Has This Been Tested?
- [ ] Unit tests
- [ ] Integration tests
- [ ] Manual testing

### Checklist
- [ ] Code follows style guidelines
- [ ] Self-review completed
- [ ] Comments added for complex code
- [ ] Documentation updated
- [ ] No new warnings

Comparison#

| Workflow    | Complexity | Best For           | Release Style |
|-------------|------------|--------------------| --------------|
| Git Flow    | High       | Versioned software | Scheduled     |
| GitHub Flow | Low        | Web apps           | Continuous    |
| Trunk-Based | Medium     | Mature teams       | Continuous    |

Conclusion#

There's no universally "best" workflow. Git Flow suits structured releases, GitHub Flow works for continuous deployment, and trunk-based development excels with experienced teams.

Start simple with GitHub Flow, and evolve as your team's needs grow.

Share this article