Understanding Git Merge vs. Rebase: Principles, Commands, and Conflict Resolution

Branch Merging

The git merge command combines two branches, for example merging branch b into the current branch. The same effect can be achieved with git rebase b , which also integrates b into the current branch.

Both commands operate on the same underlying principle: they integrate changes from one line of development into another.

Example Scenario

Assume you create a local branch mywork from the remote origin :

$ git checkout -b mywork origin

You then make two commits on mywork while other developers add commits to origin , causing the two branches to diverge.

To incorporate the remote changes you can either pull and merge, producing a merge commit, or rebase to rewrite mywork 's history onto the latest origin :

$ git checkout mywork
$ git rebase origin

During a rebase Git temporarily stores each of your commits as patches, updates mywork to the tip of origin , and then reapplies the patches.

If the rebase succeeds, the old commits become unreachable and may be removed by garbage collection ( git gc ).

Resolving Conflicts

If conflicts arise, Git pauses the rebase. After fixing the conflicted files, stage them with git add and continue the rebase:

$ git rebase --continue

You can abort the rebase at any time, returning mywork to its pre‑rebase state:

$ git rebase --abort

Merge vs. Rebase Differences

Using git merge results in a commit history that includes a merge commit (e.g., C7, C6, C4, C5, C3, C2, C1). Using git rebase creates linearized copies of the original commits (C6', C5') so the history appears as C7, C6, C5, C4, C3, C2, C1 from the user's perspective.

Thus, rebase produces a cleaner, linear history, while merge preserves the true branching structure.