Git Merge vs Rebase: Differences, Examples and When to Use Each

Your feature branch is behind main, and you need the new work. Git merge vs rebase is the choice between two ways of getting it, and both are correct. They differ in what your history looks like afterwards.

We built one tiny repository, ran both commands and pasted the real output below, so you can compare the result instead of imagining it. New to Git? Start with our Git tutorial for beginners.

What git merge and git rebase do

git merge takes the tips of two branches and combines them. If both branches have new commits, Git creates a merge commit with two parents. Nothing that already exists is changed.

git rebase takes the commits unique to your branch, sets them aside, moves your branch to the tip of the other branch and then replays your commits one by one. The replayed commits are new commits with new hashes, even though their changes are the same.

Git merge in practice

Our starting point: commit A on main, two commits (F1, F2) on feature, and one more commit (M1) added to main afterwards. Now we merge main into feature.

git switch feature
git merge main
git log --oneline --graph

*   f507aab Merge main into feature
|\
| * 8842fb5 M1
* | 082cc6a F2
* | 5a71e3c F1
|/
* 8766865 A

The graph shows the real story: two lines of work that were joined. The original commits F1 and F2 keep their hashes. The cost is an extra merge commit, and on a busy project the graph turns into a web.

Git rebase in practice

Same starting point, but this time we rebase feature onto main.

git switch feature
git rebase main
git log --oneline --graph

* 1ff474b F2
* bf9149e F1
* 8842fb5 M1
* 8766865 A

The history is one straight line, as if you had started your work after M1. Look at the hashes: F1 was 5a71e3c and is now bf9149e, and F2 changed from 082cc6a to 1ff474b. Git rewrote them, and that is why rebase needs care.

Merge vs rebase side by side

The golden rule of rebasing

Do not rebase commits that exist outside your own repository. After a rebase your branch no longer matches the copy on the server, so pushing needs a force. If a colleague built work on the old commits, their history now disagrees with yours, and sorting that out is painful.

Rebasing your private feature branch is fine. Rebasing main or any branch others use is not.

A safe team workflow

This routine keeps history clean without surprising anyone. It is also what most teams use in front of their CI pipeline, such as the one in our GitHub Actions CI/CD guide.

git switch feature
git fetch origin
git rebase origin/main        # or: git pull --rebase
# fix conflicts, then: git add <file> && git rebase --continue
git push --force-with-lease   # only on your own branch

--force-with-lease refuses to overwrite the server branch if someone pushed to it since you last fetched, which plain --force would silently destroy. When the pull request is approved, merge it into main.

How to undo a bad rebase

A rebase looks destructive, but the old commits stay in Git’s reflog for a while, so you can go back.

git reflog                    # find the commit before the rebase
git reset --hard HEAD@{5}     # example position, check reflog first

Create a backup branch with git branch backup before any risky rebase, and recovery becomes one command. Running a database or tools in containers on the side? See our Docker tutorial for beginners.

Final thoughts

Merge keeps the truth, rebase keeps it tidy. Use rebase to refresh your own branch, use merge to deliver it, and never rewrite history that other people depend on.

Frequently asked questions

Keep learning