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.

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!

Git merge vs rebase