< _

Git Rebase vs Merge Explained

Abstract generated cover for Git Rebase vs Merge Explained.

`merge` and `rebase` are two ways to bring Git histories together. They can both solve the same basic problem:

My branch started from older code, and now I need to include newer changes from another branch. The difference is how Git records the history. Merge preserves the branch history as it happened. Rebase rewrites your branch so it looks like it started from a newer point. Both are useful. Both can be misused.

The Mental Model

Imagine `master` has moved forward while you were working on a feature branch. ```plain text master: A---B---C \ feature: D---E

Your branch started at \`A\`, but \`master\` now has commits \`B\` and \`C\`.
You want your feature branch to include the latest \`master\`.
You can merge:
```plain text
master:  A---B---C
          \     \
feature:  D---E--M

Or you can rebase: ```plain text master: A---B---C \ feature: D'---E'

The code may end up the same. The history looks different.
## What Merge Does
Merge combines two branches without pretending they were developed in a straight line.
From your feature branch:
```bash
git merge master

Git creates a merge commit if needed. The merge commit says:

This branch includes work from both histories. Merge is honest about the shape of the work. It keeps the record that the branch split off and later came back together. That can be useful on shared branches because it avoids rewriting commits that other people might already have.

What Rebase Does

Rebase takes your branch commits and replays them on top of another branch. From your feature branch:

git rebase master

Before: ```plain text A---B---C master \ D---E feature

After:
```plain text
A---B---C  master
        \
         D'---E'  feature

The apostrophes matter. `D'` and `E'` are new commits. They contain the same changes as `D` and `E`, but they are not the exact same commit objects. That is why rebase is considered history rewriting.

Why Use Merge?

Merge is useful when you want to preserve history clearly. Use merge when:

  • the branch is shared with other people
  • you want to avoid rewriting commits
  • the project prefers explicit merge commits
  • the branch history is meaningful Merge is often the safer default when you are unsure. Example:
git switch feature-branch
git merge master

If there are conflicts, resolve them, stage the fixed files, and commit the merge.

Why Use Rebase?

Rebase is useful when you want a cleaner, linear history. Use rebase when:

  • the branch is your own local work
  • you have not shared the commits yet
  • you want to update your branch before opening a pull request
  • the project prefers linear history Example:
git switch feature-branch
git fetch origin
git rebase origin/master

After rebasing, your branch appears as if it started from the latest `master`. That can make review easier because the final history is less noisy.

The Important Safety Rule

Do not casually rebase commits that other people already pulled. Rebase rewrites commit identities. If someone else has your old commits, and you replace them with rebased commits, their Git history can become confusing. A simple rule:

Rebase your own local branch. Merge shared branches. That rule is not perfect for every team, but it keeps you out of most trouble.

Handling Conflicts

Both merge and rebase can produce conflicts. A conflict means Git could not automatically combine changes. During a merge, you usually fix conflicts and then commit:

git status
git add fixed-file.py
git commit

During a rebase, you fix conflicts and continue the rebase:

git status
git add fixed-file.py
git rebase --continue

If the rebase gets messy and you want to stop:

git rebase --abort

That takes you back to where you were before the rebase started.

Common Mistakes

Mistake 1: Treating rebase as magic cleanup

Rebase can make history cleaner, but it does not make bad changes good. You still need to review your code and run tests.

Mistake 2: Rebasing shared work without warning

This is the classic rebase problem. If other people depend on those commits, rewriting them creates extra work for everyone.

Mistake 3: Panicking during conflicts

Conflicts are normal. Run `git status`, read what Git is asking for, fix the files, and continue the operation.

Where This Shows Up in Real Projects

On a personal project, rebase is useful for keeping a feature branch current before merging. On a team project, merge is often better for branches that multiple people are using. In both cases, the goal is the same:

  • include the latest work
  • keep the repository understandable
  • avoid losing changes The best choice is the one that matches how the project manages history.

Key Takeaways

  • Merge combines histories and preserves the branch shape.
  • Rebase replays commits on top of another branch and rewrites commit identities.
  • Rebase local work. Be careful rebasing shared work.
  • Use `git status` when conflicts happen.

  • Choose the command based on the history you want, not because one is always better.

    Related Articles

  • Git Branching Explained: Feature Branch to Master

  • Terminal Tools I Actually Use
  • Setting Up a Mac for Development

← Back to Blog Index