Git - Difference between merge and rebase

Last modified: 2018-08-27 09:56

---

Let's go back to basics: Git.

This powerful versioning tool is hugely underestimated by newcomers because "Oh jeez it's so hard to understand what's the difference between git pull origin master and git merge origin/master, and what the hell is this slash in the middle"?

Yeah, just trolling, but actually there's something awesome we can do and that's very simple "in the end": rebasing.

Start from here.

* 33facc8  (master) Commit 3
|
| * 3b36f32  (second_branch) Detached commit
| |
|/
* 29af11f  Commit 2
|
* 1439f8e  Commit 1

We will work on branch second_branch, which is created based on a previous version of the master branch. The second_branch has one commit more than master. But, between now and when I created the branch, someone commited on master.

Our branches diverge.

Problem: I need the modifications from Commit 3 to work on my branch (or my lead developer wants me to always keep my working directory up to date with the master).

Two possibilities here:

Use merge (or pull for the lazy ones).
Use rebase.

Reminder: we work on second_branch. It means we previously ran a git checkout second_branch command.

Result of a `git merge master`

*   63c6403  (master) Merge "second_branch" in "master"
|\
| |
* | 33facc8 Commit 3
| |
| * 3b36f32  (second_branch) Detached commit
| |
|/
* 29af11f  Commit 2
|
* 1439f8e  Commit 1

As the branches diverge, we cannot fast-forward (a good doc about fast-forward, by Atlassian guys) the process of merging, so Git creates what we call a merge commit to apply all modifications of the master branch into the second_branch.

It creates a new ugly edge to the git graph.

BUT, it keeps consistency with all commits because they don't change.

Note: Something that's cool with this is that if you remove only the merge commit (number 63c6403 in our case) from the tree (with a rebase -i or a reset), then all the commits from the branch that was merged are also detached from the branch.
This allows very easy rollback when you have to merge tons of commits from a branch and that it does not satisfy the needs and you have to remove them: simply remove the merge commit and it's done.

Result of a `git rebase master`

* a018520  (HEAD -> second_branch) Detached commit
|
* 33facc8  (master) Commit 3
|
* 29af11f  Commit 2
|
* 1439f8e  Commit 1

The previous HEAD(pointer to the last commit of the currently selected branch) of my second_branch was "Commit 2", and by running git rebase, I want this HEAD to be the same as the master branch, so branches are identical at first, and then come my new commits from second_branch.

It creates a very beautiful and linear tree.

BUT, the tree changes, because the base hash for Detached commit (in the second_branch) was 3b36f32 at first, and has changed to a018520 after rebasing. It means that if somebody was using the second_branch, it will be very tricky for him to retrieve the entire new second_branch because its tree has changed completely.

It's a bit complex, I admit, but actually it's changing the old "base commit" for this branch to the "new" base.

If you need to have a better representation, you can take a look on google images for some graphs of git rebase. It's pretty cool.

Summary

`git merge {branch}`

Applies modifications of the {branch} branch to the current branch, and if branches diverge (or --no-ff is specified), it will create a new "merge commit" indicating that the two branches were merged.

`git rebase {branch}`

Rewrites the current branch history . At first, it keeps all "new commits" of the current branch (starting from head) in memory, then applies all "missing" commits from the {branch} (which should inexorably fast-forward), and finally applies all kept-in-memory commits' modifications from the current branch, one-by-one, until every conflict (if there are some) is resolved, and changes the new commits' hashes.

And rebasing is just one component of Git.

Just look at for-each-ref command, or even log, you can do beautiful things with them!