Git Workflows (GitFlow, Trunk-based) - Git & Version Control

Git Workflows

Different teams use different workflows. The right choice depends on your project.

GitHub Flow

Simplest approach. Recommended for most projects.

Rules

main branch is always deployable
Create feature branches from main
Commit with descriptive messages
Create pull request for review
After approval, merge to main
Deploy immediately after merge

Branch Structure

main (production)
├── feature/search
├── feature/auth
└── hotfix/security-patch

Workflow

# 1. Create feature branch
git checkout -b feature/dark-mode
 
# 2. Make commits
git commit -m "Add dark mode toggle"
git commit -m "Add dark mode CSS"
 
# 3. Create PR
git push -u origin feature/dark-mode
# Create PR on GitHub
 
# 4. Get approval, pass tests
 
# 5. Merge to main
# (via GitHub UI or:)
git checkout main
git pull
git merge --no-ff feature/dark-mode
git push
 
# 6. Deploy immediately

Git Flow

Complex workflow for projects with multiple release versions.

Branches

Branch	Purpose	Created From
`main`	Production releases	develop
`develop`	Integration branch	n/a
`feature/*`	New features	develop
`release/*`	Release prep	develop
`hotfix/*`	Production fixes	main

Structure

main ──────────────── v1.0 ─────────────── v1.1 ──────
      │                 │                    │
      ├─ hotfix ────────┘                    │
      │                                      │
develop ───┬─ feature/A ────┬──────────── release/1.1
           │                │            │
           ├─ feature/B ────┘            │
           │                             merge
           └──────────────────────────────┘

When to Use

✅ Enterprise projects
✅ Multiple supported versions
✅ Scheduled releases
❌ Continuous deployment
❌ Startup iterating fast

Trunk-Based Development

All developers work on main branch with short-lived feature branches.

Rules

Everyone develops on short-lived branches
Branches live less than 1 day
Frequent small merges to main
Main always deployable
Feature flags for in-progress work

Structure

main: A → B → C → D → E → F
      └─ person1-feature (1 hour)
         └─ person2-bugfix (2 hours)
            └─ person3-refactor (3 hours)

Benefits

✅ Fewer merge conflicts
✅ Continuous integration
✅ Faster feedback
✅ Easier rollback
❌ Requires discipline
❌ Needs feature flags

Feature Flags

Use feature flags to control in-progress features:

if (featureFlags.darkMode) {
    // Render dark mode UI
}
 
// Can be deployed to main/production
// But feature hidden until flag enabled

This enables:

Deploying unfinished features
A/B testing
Gradual rollout
Quick disable if issues

Release Management Strategies

Release Branch

# Create release branch
git checkout -b release/v1.2.0
 
# Final fixes, version bumps
# No new features
 
# Merge to main when ready
git push origin release/v1.2.0
 
# Create tag
git tag v1.2.0
 
# Merge back to develop
git checkout develop
git merge release/v1.2.0

Hotfix Branch

For production emergency fixes:

# Create from main
git checkout -b hotfix/security-patch main
 
# Fix issue
git commit -m "Fix SQL injection vulnerability"
 
# Merge to main
git checkout main
git merge hotfix/security-patch
 
# Also merge to develop
git checkout develop
git merge hotfix/security-patch
 
# Tag and deploy
git tag v1.0.1

Team Practices

Commit Message Guidelines

Follow convention:

# Type: feature, fix, docs, refactor, test, chore
 
# Good
git commit -m "feature: Add search functionality"
git commit -m "fix: Handle null user in auth"
git commit -m "docs: Update API documentation"
 
# Detailed message
git commit -m "fix: Prevent race condition in cache
 
Race condition occurred when multiple processes
accessed cache simultaneously. Added mutex lock
to ensure atomic updates.
 
Fixes issue #345"

Code Review Standards

Things to check:
- Does it solve the problem described?
- Is code readable and maintainable?
- Are there tests?
- Any performance concerns?
- Security implications?
- Follows project conventions?

PR Size Recommendations

Size	Status
under 100 lines	✅ Ideal
100-400 lines	⚠️ Acceptable
400-1000 lines	⚠️ Consider splitting
over 1000 lines	❌ Too large

CI/CD Integration

Automate with continuous integration:

# When PR created, automatically:
npm run lint    # Check style
npm run test    # Run tests
npm run build   # Build project
 
# If all pass, show "Ready to merge"
# If any fail, show "Review failed"

Deployment Strategies

Immediate Deployment (GitHub Flow)

PR → Merge → Deploy to production immediately

Best for: Startups, rapid iteration

Staged Deployment (Git Flow with release branch)

PR → Merge → Staging → Testing → Production release

Best for: Enterprise, multiple environments

Canary Deployment

Deploy to 5% of users → Monitor → Gradually increase to 100%

Best for: Large user base, high-risk changes

Choosing Your Workflow

Criteria	GitHub Flow	Git Flow	Trunk-Based
Team Size	Any	Large	Experienced
Release Frequency	Continuous	Scheduled	Continuous
Complexity	Simple	Complex	Simple (with discipline)
Learning Curve	Easy	Moderate	Easy
CI/CD Required	Yes	No	Yes

Tips

✓ Choose workflow that fits your team
✓ Automate with CI/CD
✓ Enforce through branch protection rules
✓ Document process for new team members
✓ Review workflow regularly
✓ Adapt as team grows
✓ Use feature flags for controlled rollouts