Git Workflows: Branching Strategies for Teams

Trunk-Based Development

main (always deployable)
  ├── feature/auth
  ├── feature/payment
  └── bugfix/login

Rules:
- Short-lived branches (< 1 day)
- Direct commits to main for small changes
- Feature flags for incomplete features

Pros

• Simplifies merging
• Always deployable main
• Fast feedback loop

Cons

• Requires discipline
• Feature flags needed
• Frequent integrations

Git Flow

main
  ├── develop
      ├── feature/user-auth
      ├── feature/payment
      ├── release/v1.0
      └── hotfix/critical-bug

Branches:
- main: Production releases
- develop: Integration branch
- feature/*: New features
- release/*: Release preparation
- hotfix/*: Production fixes

Workflow

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

# Work on feature
git add .
git commit -m "Add login page"

# Finish feature
git checkout develop
git merge feature/user-auth
git branch -d feature/user-auth

# Start release
git checkout develop
git checkout -b release/v1.0

# Finish release
git checkout main
git merge release/v1.0  # Production release
git checkout develop
git merge release/v1.0  # Back to develop

# Hotfix
git checkout main
git checkout -b hotfix/critical-bug
# Fix bug
git checkout main
git merge hotfix/critical-bug
git checkout develop
git merge hotfix/critical-bug

Pros

• Structured release process
• Parallel development
• Clear separation

Cons

• Complex for small teams
• Overhead for simple projects

GitHub Flow

main (protected, always deployable)
  ├── feature/auth (PR)
  ├── feature/payment (PR)
  └── bugfix/login (PR)

Workflow:
1. Branch from main
2. Commit to branch
3. Open Pull Request
4. Code review & discuss
5. Merge to main
6. Deploy immediately

Example

bash
# 1. Create branch
git checkout main
git pull
git checkout -b feature/user-auth

# 2. Make commits
git add .
git commit -m "Add login page"
git commit -m "Add OAuth integration"

# 3. Push & create PR
git push -u origin feature/user-auth
# Create PR on GitHub

# 4. After review & merge
git checkout main
git pull

# 5. Delete branch
git branch -d feature/user-auth

Pros

• Simple & effective
• Code reviews required
• Continuous deployment friendly

Cons

• Large features can have long-lived branches
• Merge conflicts in large teams

GitLab Flow

main (production)
  ├── develop (staging)
      ├── feature/auth
      └── feature/payment

Environment-specific branches:
- main → production
- develop → staging
- feature/* → review apps

Workflow

bash
# Feature branch with review app
git checkout develop
git checkout -b feature/new-ui

# Push (creates review app)
git push -u origin feature/new-ui

# Merge to staging
git checkout develop
git merge feature/new-ui

# Deploy to staging, test
# When ready, merge to main
git checkout main
git merge develop

# Deploy to production

Pros

• Environment branches
• Review apps
• Tracked deployments

Cons

• More complex
• Requires CI/CD setup

Choosing a Workflow

Small team (1-5 developers):
→ GitHub Flow

Medium team (5-20 developers):
→ Git Flow or Trunk-Based

Large team (20+ developers):
→ GitLab Flow or Trunk-Based

Continuous Deployment:
→ Trunk-Based or GitHub Flow

Multiple Environments:
→ GitLab Flow or Git Flow

Frequent Releases:
→ Trunk-Based

Scheduled Releases:
→ Git Flow

Branch Naming Conventions

bash
# Features
feature/user-auth
feature/add-payment
feat/oauth-login

# Bug fixes
bugfix/login-error
fix/crash-on-startup

# Hotfixes
hotfix/security-patch
hotfix/critical-bug

# Releases
release/v1.0.0
release/v2.1.0

# Experiments
experiment/new-ui-prototype
spike/cache-strategy

# Refactoring
refactor/user-service
refactor/optimize-db-queries

Commit Messages

bash
# Conventional Commits
<type>(<scope>): <subject>

Types:
- feat: New feature
- fix: Bug fix
- docs: Documentation
- style: Formatting
- refactor: Code change
- test: Adding tests
- chore: Maintenance

Examples:
feat(auth): add OAuth2 login
fix(payment): handle declined cards
docs(api): update authentication guide
refactor(user): extract validator function

Protected Branches

yaml
# GitHub/GitLab settings
main:
  - Require pull request reviews
    - Required reviewers: 2
    - Dismiss stale reviews
  - Require status checks
    - CI: passing
    - Tests: passing
  - Require branches to be up to date
  - Include administrators
  - Restrict who can push

CI/CD Integration

yaml
# .github/workflows/ci.yml
name: CI

on:
  pull_request:
    branches: [main, develop]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
      - run: npm ci
      - run: npm test
      - run: npm run lint

Choose the workflow that fits your team!