Merge vs Squash vs Rebase Pull Request: Key Differences and Usage

In Git, a merge pull request combines all commits preserving history, a squash pull request condenses all commits into one for a cleaner history, and a rebase pull request rewrites commits on top of the target branch for a linear history. Each method affects commit history and collaboration differently.

Quick Comparison

Here is a quick table comparing merge, squash, and rebase pull requests based on key factors.

Factor	Merge	Squash	Rebase
Commit History	Preserves all commits as separate entries	Combines all commits into one	Rewrites commits on top of target branch
History Cleanliness	Can be cluttered with many commits	Keeps history clean and simple	Keeps history linear and clean
Conflict Resolution	Conflicts resolved once during merge	Conflicts resolved once during squash merge	Conflicts may need resolving during rebase
Traceability	Full commit details preserved	Single commit loses individual commit details	Full commit details preserved but rewritten
Use Case	When preserving full history is important	When you want a tidy, single commit	When you want a linear history without merge commits

Key Differences

Merge pull requests combine the feature branch into the target branch by creating a new merge commit. This preserves the entire commit history, showing all individual commits and their order. It is useful when you want to keep a detailed record of all changes but can make history complex.

Squash pull requests take all commits from the feature branch and combine them into a single commit before merging. This results in a cleaner, simpler history with one commit representing the entire feature. However, it loses the granularity of individual commits.

Rebase pull requests rewrite the feature branch commits to appear as if they were made on top of the latest target branch commit. This creates a linear history without merge commits. It preserves commit details but changes commit hashes, which can complicate collaboration if not coordinated.

Code Comparison

Here is how you would merge a feature branch into main using merge:

bash

git checkout main
git pull origin main
git merge feature-branch
git push origin main

Output

Updating abc1234..def5678
Merge made by the 'recursive' strategy.
 file1.txt | 2 ++
 1 file changed, 2 insertions(+)

Squash Equivalent

To squash commits from a feature branch into one before merging:

bash

git checkout main
git pull origin main
git merge --squash feature-branch
git commit -m "Add feature as single commit"
git push origin main

Output

[main abcdef1] Add feature as single commit
 3 files changed, 15 insertions(+)

When to Use Which

Choose merge when you want to keep a full, detailed history of all commits and understand the development process step-by-step.

Choose squash when you prefer a clean, simple history with one commit per feature, making the log easier to read.

Choose rebase when you want a linear history without merge commits, especially before merging, but be careful to coordinate with your team to avoid conflicts.

Key Takeaways

Merge preserves all commits and creates a merge commit, keeping full history.

Squash condenses all commits into one, simplifying history but losing detail.

Rebase rewrites commits on top of the target branch for a clean, linear history.

Use merge for detailed history, squash for clean single commits, and rebase for linear history.

Coordinate with your team when using rebase to avoid collaboration issues.