cherry-pick as a Basis for 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...

• Beyond cherry-pick – How to Use git 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...

It is useful to think of rebase as performing git cherry-pick – a command takes a commit, computes the patch this commit introduces by computing the difference between the parent's commit and the commit itself, and then cherry-pick "replays" this difference.

Let's do this manually.

If we look at the difference introduced by "Commit 5" by performing git diff main <SHA_OF_COMMIT_5>:

Running git diff to observe the patch introduced by "Commit 5"
<Source: Brief>

Note

If you want to play around with the repository I used and try out the commands for yourself, you can get the repo here (Omerr/rebase_playground).

Omerr/rebase_playground

A post accompanying the video tutorial: https://youtu.be/3VFsitGUB3s

You can see that in this commit, John started working on a song called "Lucy in the Sky with Diamonds":

The output of git diff - the patch introduced by "Commit 5"
<Source: Brief>

As a reminder, you can also use the command git show to get the same output:

git show <SHA_OF_COMMIT_5>

Now, if you cherry-pick this commit, you will introduce this change specifically, on the active branch. Switch to main first:

git checkout main
# or
git switch main

And create another branch, just to be clear:

git checkout -b my_branch
# or
git switch -c my_branch

Creating my_branch that branches from main
<Source: Brief>

And cherry-pick this commit:

git cherry-pick <SHA_OF_COMMIT_5>

Using cherry-pick to apply the changes introduced in "Commit 5" onto main
<Source: Brief>

Consider the log (output of git lol):

The output of git lol
<Source: Brief>

Note

git lol is an alias I added to Git to visibly see the history in a graphical manner. You can find it here (Omerr).

git lol

git log --graph \
--pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' \
--abbrev-commit

To configure as an alias git lol:

git config --global alias.lol \
"log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

It seems like you copy-pasted "Commit 5". Remember that even though it has the same commit message, and introduces the same changes, and even points to the same tree object as the original "Commit 5" in this case – it is still a different commit object, as it was created with a different timestamp.

Looking at the changes, using git show HEAD:

The output of git show HEAD
<Source: Brief>

They are the same as "Commit 5"'s.

And of course, if you look at the file (say, by using nano lucy_in_the_sky_with_diamonds.md), it will be in the same state as it has been after the original "Commit 5".

Cool! 😎

OK, you can now remove the new branch so it doesn't appear on your history every time:

git checkout main
git branch -D my_branch

---

Beyond cherry-pick – How to Use git rebase

You can look at git rebase as a way to perform multiple cherry-picks one after the other – that is, to "replay" multiple commits. This is not the only thing you can do with rebase, but it's a good starting point for our explanation.

It's time to play with git rebase! 👏🏻👏🏻

Before, you merged paul_branch into john_branch. What would happen if you rebased paul_branch on top of john_branch? You would get a very different history.

In essence, it would seem as if we took the changes introduced in the commits on paul_branch, and replayed them on john_branch. The result would be a linear history.

To understand the process, I will provide the high level view, and then dive deeper into each step. The process of rebasing one branch on top of another branch is as follows:

1. Find the common ancestor.
2. Identify the commits to be "replayed".
3. For every commit X, compute diff(parent(X), X), and store it as a patch(X).
4. Move HEAD to the new base.
5. Apply the generated patches in order on the target branch. Each time, create a new commit object with the new state.

The process of making new commits with the same changesets as existing ones is also called "replaying" those commits, a term we have already used.