Git Workflow and Branching Strategies

Git workflows define how teams collaborate on code using branches. This guide covers the most popular Git workflows and branching strategies used in modern software development.

Why Branching Strategies Matter #

Without a clear branching strategy:

  • Merge conflicts become frequent and complex
  • Difficult to track feature development
  • Hard to maintain stable production code
  • Release management becomes chaotic

Common Git Workflows #

1. Feature Branch Workflow #

The simplest workflow where each feature gets its own branch.

How it works:

# Start from main
git checkout main
git pull origin main

# Create feature branch
git checkout -b feature/user-authentication

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

# Push to remote
git push origin feature/user-authentication

# Create pull request and merge to main

Pros:

  • Simple to understand
  • Clear feature isolation
  • Easy code review process

Cons:

  • No separate staging environment
  • All features go directly to production

2. Git Flow #

A comprehensive workflow with multiple branch types.

Branch Types:

  • main - Production-ready code
  • develop - Integration branch for features
  • feature/* - New features
  • release/* - Release preparation
  • hotfix/* - Emergency production fixes

Workflow:

# Start new feature
git checkout develop
git checkout -b feature/shopping-cart

# Work on feature
git add .
git commit -m "Implement shopping cart"

# Finish feature
git checkout develop
git merge feature/shopping-cart
git branch -d feature/shopping-cart

# Start release
git checkout develop
git checkout -b release/1.0.0

# Fix release bugs
git commit -m "Fix typo in checkout"

# Finish release
git checkout main
git merge release/1.0.0
git tag -a v1.0.0 -m "Release 1.0.0"

git checkout develop
git merge release/1.0.0
git branch -d release/1.0.0

# Create hotfix
git checkout main
git checkout -b hotfix/critical-bug

# Fix and commit
git commit -m "Fix critical security issue"

# Merge to main and develop
git checkout main
git merge hotfix/critical-bug
git tag -a v1.0.1 -m "Hotfix 1.0.1"

git checkout develop
git merge hotfix/critical-bug
git branch -d hotfix/critical-bug

Pros:

  • Clear separation of concerns
  • Supports multiple versions
  • Formal release process

Cons:

  • Complex for small teams
  • More branches to manage
  • Overhead for continuous deployment

3. GitHub Flow #

A simplified workflow optimized for continuous deployment.

Rules:

  1. main branch is always deployable
  2. Create descriptive branches from main
  3. Commit to branch regularly
  4. Open pull request for discussion
  5. Merge after approval and tests pass
  6. Deploy immediately after merge

Workflow:

# Create feature branch
git checkout main
git pull origin main
git checkout -b add-payment-processing

# Make changes
git add .
git commit -m "Add Stripe integration"
git push origin add-payment-processing

# Open pull request on GitHub
# After approval and CI passes
git checkout main
git merge add-payment-processing
git push origin main

# Deploy to production
# Delete feature branch
git branch -d add-payment-processing
git push origin --delete add-payment-processing

Pros:

  • Simple and easy to follow
  • Fast iteration
  • Perfect for continuous deployment

Cons:

  • No separate staging
  • Requires robust CI/CD
  • Not ideal for scheduled releases

4. GitLab Flow #

Combines feature branches with environment branches.

Branches:

  • main - Latest development
  • pre-production - Staging environment
  • production - Production environment

Workflow:

# Create feature
git checkout main
git checkout -b feature/notifications

# Develop and commit
git add .
git commit -m "Add email notifications"

# Merge to main
git checkout main
git merge feature/notifications

# Deploy to staging
git checkout pre-production
git merge main

# After QA approval, deploy to production
git checkout production
git merge pre-production

Pros:

  • Environment branches match deployments
  • Clear promotion path
  • Supports staged releases

Cons:

  • More branches to maintain
  • Can be slower than GitHub Flow

5. Trunk-Based Development #

Developers work on short-lived branches or directly on trunk.

Rules:

  • main (trunk) is always releasable
  • Very short-lived feature branches (< 1 day)
  • Frequent integration to main
  • Feature flags for incomplete features

Workflow:

# Small changes go directly to main
git checkout main
git pull origin main

# Make small change
git add .
git commit -m "Update button color"
git push origin main

# Larger features use short-lived branches
git checkout -b quick-feature
# Work for a few hours
git add .
git commit -m "Add feature"

# Merge same day
git checkout main
git merge quick-feature
git push origin main
git branch -d quick-feature

Pros:

  • Minimal merge conflicts
  • Fast integration
  • Simplifies CI/CD

Cons:

  • Requires feature flags
  • Needs strong testing
  • Not suitable for large features

Branch Naming Conventions #

Feature Branches #

feature/user-authentication
feature/shopping-cart
feature/payment-integration

Bug Fixes #

bugfix/login-error
bugfix/cart-calculation
fix/typo-homepage

Hotfixes #

hotfix/security-patch
hotfix/critical-bug

Release Branches #

release/1.0.0
release/2.1.0

Experimental #

experiment/new-algorithm
spike/performance-test

Essential Git Commands #

Creating and Switching Branches #

# Create and switch to new branch
git checkout -b feature/new-feature

# Modern syntax
git switch -c feature/new-feature

# Create branch without switching
git branch feature/new-feature

# Switch to existing branch
git checkout feature/new-feature
git switch feature/new-feature

Merging Strategies #

Fast-Forward Merge:

git checkout main
git merge feature/simple-change
# Creates linear history

No Fast-Forward Merge:

git checkout main
git merge --no-ff feature/important-feature
# Creates merge commit

Squash Merge:

git checkout main
git merge --squash feature/many-commits
git commit -m "Add complete feature"
# Combines all commits into one

Rebase:

git checkout feature/my-feature
git rebase main
# Replays commits on top of main

Managing Branches #

# List all branches
git branch                  # Local
git branch -r              # Remote
git branch -a              # All

# Delete branch
git branch -d feature/done             # Safe delete
git branch -D feature/force-delete     # Force delete

# Delete remote branch
git push origin --delete feature/done

# Rename branch
git branch -m old-name new-name

# Track remote branch
git checkout -b feature/remote origin/feature/remote

Keeping Branches Updated #

# Update feature branch with main
git checkout feature/my-feature
git merge main

# Or use rebase for cleaner history
git checkout feature/my-feature
git rebase main

# Pull latest from remote
git pull origin main
git pull --rebase origin main  # With rebase

Stashing Changes #

# Save current work
git stash

# Save with message
git stash save "Work in progress"

# List stashes
git stash list

# Apply most recent stash
git stash apply

# Apply and remove stash
git stash pop

# Apply specific stash
git stash apply stash@{2}

# Clear all stashes
git stash clear

Pull Request Best Practices #

Creating Good PRs #

  1. Small and Focused - One feature per PR
  2. Descriptive Title - Clear summary of changes
  3. Detailed Description - What, why, and how
  4. Link Issues - Reference related tickets
  5. Add Screenshots - For UI changes
  6. Request Reviewers - Assign appropriate people

Example PR Description:

## What
Add user authentication using JWT tokens

## Why
Users need to securely log in to access protected features

## How
- Implemented JWT token generation
- Added login/logout endpoints
- Created authentication middleware
- Updated user model with password hashing

## Testing
- Added unit tests for auth functions
- Manual testing of login flow
- Verified token expiration

## Screenshots
[Attach login page screenshot]

Closes #123

Code Review Guidelines #

As Author:

  • Respond to all comments
  • Don’t take feedback personally
  • Make requested changes promptly
  • Mark conversations as resolved

As Reviewer:

  • Be constructive and specific
  • Suggest improvements, don’t demand
  • Approve when satisfied
  • Use questions for understanding

Handling Merge Conflicts #

# When merge conflict occurs
git checkout main
git merge feature/conflict

# CONFLICT (content): Merge conflict in file.js
# Edit files to resolve conflicts

# Look for conflict markers
<<<<<<< HEAD
current code
=======
incoming code
>>>>>>> feature/conflict

# After resolving
git add file.js
git commit -m "Resolve merge conflict"

Protecting Branches #

Configure branch protection on GitHub:

Settings → Branches → Branch protection rules

Rules:
✓ Require pull request reviews
✓ Require status checks to pass
✓ Require branches to be up to date
✓ Include administrators
✓ Restrict who can push

Choosing the Right Workflow #

Team SizeRelease CadenceChoose
Small (1-5)ContinuousGitHub Flow
Small (1-5)ScheduledFeature Branch
Medium (5-20)ContinuousTrunk-Based
Medium (5-20)ScheduledGitLab Flow
Large (20+)Multiple versionsGit Flow

Tips for Success #

  1. Commit Often - Small, focused commits
  2. Write Good Messages - Explain why, not what
  3. Pull Before Push - Stay synced with team
  4. Delete Merged Branches - Keep repo clean
  5. Use Tags - Mark releases
  6. Automate - Use CI/CD for testing
  7. Document - Explain your workflow in README

A solid Git workflow prevents chaos and enables smooth collaboration. Choose one that fits your team size and release process, then stick to it consistently.