Git HelpMerge or rebase: which to use
Both bring work from one branch into another. They leave different histories.
What each one does
- Merge keeps both lines of history and adds a merge commit that joins them. Nothing already written is changed.
- Rebase takes your commits and writes them again on top of the other branch. The history becomes one straight line, and your commits get new hashes.
The conflict page of this site printed the graph after a merge, a line with a branching shape and a merge commit at the top. The rebase page printed a straight line.
A simple rule
- Work only you have: rebase to tidy it before you share it.
- Work other people also use: merge, because rebasing it would rewrite commits they already have.
- When unsure, merge. It never hides what happened.
Conflicts
In both cases Git can stop and ask you to fix a conflict. With a merge you fix it once. With a rebase you may have to fix it for each commit that conflicts, then run git rebase --continue; to give up, run git rebase --abort.
Does rebase lose my work?
Not normally, and the old commits stay in the reflog for a while. Still, make a copy of the branch first if the work matters: git branch backup.
What does the merge commit contain?
Usually no changes of its own. It records that two lines of history were joined.
Sources
- Git documentation: git-reset (git-scm.com/docs/git-reset)
- Git documentation: gitrevisions (git-scm.com/docs/gitrevisions)
- Git documentation: git-config, settings gc.reflogExpire and gc.reflogExpireUnreachable (git-scm.com/docs/git-config)
- Git documentation: git-revert (git-scm.com/docs/git-revert)
Read on 14 November 2026.
This is an independent guide. It is not connected with the Git project, GitHub, GitLab or any company named here. Every command below was run on 14 November 2026 with the real program (git version 2.56.0.windows.4) in a new empty practice repository; the output shown is what it printed. Facts about options were read in the official Git documentation on 14 November 2026.