The debate between git rebase and merge is one of the most common discussions in development teams. Both commands integrate changes from one branch into another, but they do it in fundamentally different ways. Understanding when to use each is crucial for maintaining a clean and meaningful project history.
Understanding the Basics
What is Git Merge?
Merge creates a new commit that combines the histories of two branches:
# Merge feature branch into main
git checkout main
git merge feature-branch
This creates a merge commit with two parent commits, preserving the complete history of both branches.
What is Git Rebase?
Rebase rewrites history by moving commits to a new base:
# Rebase feature branch onto main
git checkout feature-branch
git rebase main
This replays your commits on top of the target branch, creating new commits with different SHAs.
Visual Comparison
Before Integration
main: A---B---C
\
feature: D---E---F
After Merge
main: A---B---C-------G (merge commit)
\ /
feature: D---E---F
After Rebase
main: A---B---C
\
feature: D'--E'--F' (new commits)
When to Use Merge
1. Preserving Context
Use merge when the branch represents a significant feature:
# Feature branch with multiple commits
git checkout main
git merge --no-ff feature/user-authentication
The merge commit serves as a historical marker for when the feature was integrated.
2. Public Branches
Never rebase commits that exist outside your local repository:
# Safe for public collaboration
git checkout main
git merge origin/feature-branch
git push origin main
3. Collaborative Features
When multiple developers work on the same branch:
# Team feature branch
git checkout team-feature
git pull origin team-feature
git checkout main
git merge team-feature
When to Use Rebase
1. Cleaning Local History
Before pushing your branch, clean up commits:
# Interactive rebase to squash commits
git rebase -i HEAD~3
# In the editor, change 'pick' to 'squash' for commits to combine
pick abc1234 Add login form
squash def5678 Fix typo
squash ghi9012 Update styles
2. Keeping Feature Branches Updated
Regularly rebase feature branches onto main:
# Update feature branch with latest main
git checkout feature-branch
git fetch origin
git rebase origin/main
3. Linear History
For projects that prefer a linear history:
# Rebase before merging
git checkout feature-branch
git rebase main
git checkout main
git merge --ff-only feature-branch
Practical Workflows
Feature Branch with Rebase
# 1. Start feature
git checkout -b feature/new-dashboard
git commit -m "Add dashboard layout"
git commit -m "Add charts component"
# 2. Update with main regularly
git fetch origin
git rebase origin/main
# 3. Clean history before PR
git rebase -i origin/main
# 4. Push (force required after rebase)
git push --force-with-lease origin feature/new-dashboard
Release Branch with Merge
# 1. Create release branch
git checkout -b release/2.0 develop
# 2. Cherry-pick fixes if needed
git cherry-pick abc1234
# 3. Merge to main
git checkout main
git merge --no-ff release/2.0
git tag -a v2.0.0 -m "Release version 2.0.0"
# 4. Merge back to develop
git checkout develop
git merge --no-ff release/2.0
Advanced Rebase Techniques
1. Rebase with Autosquash
# Mark commits for automatic squashing
git commit --fixup=abc1234
git commit --squash=def5678
# Rebase with autosquash
git rebase -i --autosquash origin/main
2. Rebase Onto Different Branch
# Move commits to different base
git rebase --onto main feature-old feature-new
3. Preserving Merge Commits
# Rebase while keeping merge commits
git rebase -p main
# or with newer Git versions
git rebase -r main
Common Pitfalls and Solutions
1. Conflicts During Rebase
# If conflicts occur during rebase
git status # See conflicted files
# Fix conflicts in editor
git add resolved-file.txt
git rebase --continue
# Or abort if needed
git rebase --abort
2. Lost Commits After Rebase
# Find lost commits
git reflog
# Restore if needed
git cherry-pick lost-commit-sha
3. Pushing After Rebase
# Safe force push
git push --force-with-lease origin feature-branch
# Never use plain --force on shared branches
# --force-with-lease ensures you don't overwrite others' work
Team Guidelines
Establish Clear Rules
Create a team agreement:
## Our Git Strategy
### Use Merge When:
- Merging to main/master
- Completing feature branches
- Integrating release branches
### Use Rebase When:
- Updating personal feature branches
- Cleaning up local commits
- Before creating pull requests
### Never Rebase:
- Public/shared branches
- Commits already on main
- After pushing to remote
Pull Request Workflow
# 1. Update and clean your branch
git fetch origin
git rebase origin/main
git rebase -i origin/main # Clean commits
# 2. Push to remote
git push --force-with-lease origin feature-branch
# 3. After PR approval, merge (don't rebase)
# Use GitHub/GitLab merge button or:
git checkout main
git merge --no-ff feature-branch
Hybrid Approaches
Rebase Locally, Merge Publicly
# Local work: rebase
git checkout feature
git rebase main
# Public integration: merge
git checkout main
git merge --no-ff feature
Squash Merging
Combine benefits of both:
# Squash all commits into one
git checkout main
git merge --squash feature-branch
git commit -m "Add complete feature"
Making the Right Choice
Choose Merge When You Want:
- Complete history preservation
- Clear feature boundaries
- Safe collaboration
- Audit trail of changes
Choose Rebase When You Want:
- Linear, clean history
- Logical commit progression
- Simplified debugging
- Cleaner git log
Best Practices
1. Communication is Key
# Add rebase notes in PR description
"This branch has been rebased onto latest main.
Force push was required. All conflicts resolved."
2. Use Aliases for Safety
# Git aliases for safer rebasing
git config --global alias.fpush 'push --force-with-lease'
git config --global alias.ri 'rebase -i'
git config --global alias.rc 'rebase --continue'
git config --global alias.ra 'rebase --abort'
3. Backup Before Rebase
# Create backup branch before risky rebase
git branch backup-feature-branch
git rebase -i origin/main
# If something goes wrong
git reset --hard backup-feature-branch
Conclusion
Neither rebase nor merge is inherently better—they're different tools for different situations. Merge preserves history and is safer for collaboration, while rebase creates cleaner history and is excellent for local cleanup.
The key is understanding your team's needs and establishing clear guidelines. Whether you choose the simplicity of merge, the cleanliness of rebase, or a hybrid approach, consistency and communication are what matter most.
Remember: when in doubt, merge is the safer choice. You can always clean up history locally with rebase before sharing your work.
Share this article
David Childs
Consulting Systems Engineer with over 10 years of experience building scalable infrastructure and helping organizations optimize their technology stack.