Git Branch Strategies: rebase vs merge and Team Workflows

Introduction

In team development, Git branching strategy is a critical factor affecting code quality and development velocity. This article compares major branching strategies and explains when to use rebase vs merge.

Branching Strategies

Git Flow

Proposed by Vincent Driessen, using multiple branch types:

Branch	Purpose	Lifecycle
`main`	Released code	Permanent
`develop`	Integration branch	Permanent
`feature/*`	New features	Temporary
`release/*`	Release preparation	Temporary
`hotfix/*`	Emergency fixes	Temporary

# Create and complete a feature branch
git checkout -b feature/user-auth develop
# ... develop ...
git checkout develop
git merge --no-ff feature/user-auth
git branch -d feature/user-auth

Best for: Products with clear release cycles, parallel version maintenance.

GitHub Flow

Simple strategy with only main and feature branches:

# 1. Branch from main
git checkout -b feature/add-search main

# 2. Commit and push
git add .
git commit -m "feat: add search functionality"
git push -u origin feature/add-search

# 3. Create Pull Request for review

# 4. Merge to main (via PR)

# 5. Deploy

Best for: Continuous deployment, web applications, small-to-medium teams.

Trunk-Based Development

All developers commit directly to main (trunk) or use short-lived branches:

# Short-lived branch (merge within 1-2 days)
git checkout -b fix/typo main
# ... fix ...
git checkout main
git merge fix/typo
git branch -d fix/typo

Best for: Teams with mature CI/CD, organizations using feature flags.

Comparison

Strategy	Complexity	Release Management	CI/CD Required	Team Size
Git Flow	High	Explicit	No	Large
GitHub Flow	Low	Simple	Recommended	Small-Medium
Trunk-Based	Medium	Continuous	Yes	Any

rebase vs merge

merge (merge commit)

git checkout main
git merge feature/add-search

Creates a merge commit
Preserves branch and merge history
Single conflict resolution point

rebase

git checkout feature/add-search
git rebase main

Replays commits on top of main
Creates linear history
May need conflict resolution per commit

Guidelines

Situation	Recommended	Reason
Updating feature branch	`rebase`	Linear history, cleaner diffs
Integrating to shared branch	`merge --no-ff`	Clear merge points
Already pushed branch	`merge`	rebase rewrites history
Solo development	`rebase`	Cleaner history
Team development	`merge` or squash	Safer, easier to understand

squash merge

Combines all feature branch commits into one:

git checkout main
git merge --squash feature/add-search
git commit -m "feat: add search functionality"

GitHub PRs support this via the “Squash and merge” button.

Commit Message Convention

Conventional Commits

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

[optional body]

[optional footer]

type	Usage
`feat`	New feature
`fix`	Bug fix
`docs`	Documentation
`refactor`	Code refactoring
`test`	Adding tests
`chore`	Build/tooling

git commit -m "feat(auth): add OAuth 2.0 login support"
git commit -m "fix(api): handle null response from payment service"

Practical Workflow

Feature Branch Workflow

# 1. Get latest main
git checkout main
git pull origin main

# 2. Create feature branch
git checkout -b feature/new-api

# 3. Periodically sync with main
git fetch origin
git rebase origin/main

# 4. Push (force-push needed after rebase)
git push -f origin feature/new-api

# 5. Create PR → Review → Merge

Conflict Resolution

# When conflicts occur during rebase
git rebase main
# ... resolve conflicts manually ...
git add <resolved-files>
git rebase --continue

# To abort the rebase
git rebase --abort

Docker Compose Practical Guide - Combine development environment setup with branching strategy.
OAuth 2.0/OIDC Introduction - Example of a feature developed on a feature branch.

References

Driessen, V. (2010). “A successful Git branching model”.
GitHub Flow
Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate. IT Revolution Press.
Conventional Commits