Time to Get Hands-On with Rebase 관련

The Git Rebase Handbook – A Definitive Guide to Rebasing

---

One of the most powerful tools a developer can have in their toolbox is git rebase. Yet it is notorious for being complex and misunderstood. The truth is, if you understand what it actually does, git rebase is a very elegant, and straightforward too...

---

The Git Rebase Handbook – A Definitive Guide to Rebasing

One of the most powerful tools a developer can have in their toolbox is git rebase. Yet it is notorious for being complex and misunderstood. The truth is, if you understand what it actually does, git rebase is a very elegant, and straightforward too...

Start from Paul's branch:

git checkout paul_branch

This is the history:

Commit history before performing git rebase
<Source: Brief>

And now, to the exciting part:

git rebase john_branch

And observe the history:

The history after rebasing
<Source: Brief>

gg

gg is an alias for an external tool (mlange-42/git-graph) I introduced in the video.

mlange-42/git-graph

Command line tool to show clear git graphs arranged for your branching model

So whereas with git merge you added to the history, with git rebase you rewrite history. You create new commit objects. In addition, the result is a linear history graph – rather than a diverging graph.

The history after rebasing
<Source: Brief>

In essence, we "copied" the commits that were on paul_branch and introduced after "Commit 4", and "pasted" them on top of john_branch.

The command is called "rebase", because it changes the base commit of the branch it's run from. That is, in your case, before running git rebase, the base of paul_branch was "Commit 4" – as this is where the branch was "born" (from main). With rebase, you asked Git to give it another base – that is, pretend as if it had been born from "Commit 6".

To do that, Git took what used to be "Commit 7", and "replayed" the changes introduced in this commit onto "Commit 6", and then created a new commit object. This object differs from the original "Commit 7" in three aspects:

1. It has a different timestamp.
2. It has a different parent commit – "Commit 6" rather than "Commit 4".
3. The tree object it is pointing to is different - as the changes were introduced to the tree pointed to by "Commit 6", and not the tree pointed to by "Commit 4".

Notice the last commit here, "Commit 9'". The snapshot it represents (that is, the tree that it points to) is exactly the same tree you would get by merging the two branches. The state of the files in your Git repository would be the same as if you used git merge. It's only the history that is different, and the commit objects of course.

Now, you can simply use:

git checkout main
git merge paul_branch

Hm.... What would happen if you ran this last command? 🤔 Consider the commit history again, after checking out main:

The history after rebasing and checking out main
<Source: Brief>

What would it mean to merge main and paul_branch?

Indeed, Git can simply perform a fast-forward merge, as the history is completely linear (if you need a reminder about fast forward merges, check out this post). As a result, main and paul_branch now point to the same commit:

The result of a fast-forward merge
<Source: Brief>