{"id":15104,"date":"2022-08-26T13:25:57","date_gmt":"2022-08-26T10:25:57","guid":{"rendered":"https:\/\/railsware.com\/blog\/?p=15104"},"modified":"2023-02-07T16:09:17","modified_gmt":"2023-02-07T13:09:17","slug":"how-to-use-git-rebase-onto","status":"publish","type":"post","link":"https:\/\/railsware.com\/blog\/how-to-use-git-rebase-onto\/","title":{"rendered":"New Level of Control with git rebase \u2011\u2011onto"},"content":{"rendered":"\n
Git rebase is a great tool to rearrange your commit history and make it tidier. But during my long history of using it, I collected a bunch of use cases that were hard to handle with a usual rebase. It turns out that rebase<\/em> has a little-known option \u2011\u2011onto<\/em> which was a game changer for me.<\/div>\n\n\n\n
\"\"<\/figure>\n\n\n\n

In a nutshell, <code data-enlighter-language="generic" class="EnlighterJSRAW">git rebase \u2011\u2011onto<\/code><\/code> allows you to move or copy a bunch of commits from one branch atop another. You can treat it as a <code data-enlighter-language="generic" class="EnlighterJSRAW">git cherry-pick<\/code><\/code> on steroids. Without further ado, let’s see it in action.<\/p>\n\n\n\n

What\u2019s the problem with rebase<\/em><\/h2>\n\n\n\n

Imagine, there is a branch <code data-enlighter-language="generic" class="EnlighterJSRAW">feature1<\/code><\/code>, that was created by your colleague. Your goal is to add some new stuff to it. You happily branched off of <code data-enlighter-language="generic" class="EnlighterJSRAW">feature1<\/code><\/code> and implemented new functionality in commits <code data-enlighter-language="generic" class="EnlighterJSRAW">C<\/code><\/code> and <code data-enlighter-language="generic" class="EnlighterJSRAW">D<\/code><\/code>. Here is what Git history looks like:<\/p>\n\n\n\n

A --- B feature1\n       \\     \n        C --- D feature2<\/code><\/pre>\n\n\n\n
While you worked on your stuff, your colleague added some new functionality in <code data-enlighter-language="generic" class="EnlighterJSRAW">feature1<\/code><\/code>. But they also like to use rebase, so they modified commit <code data-enlighter-language="generic" class="EnlighterJSRAW">B<\/code><\/code> a bit. On the diagram below, it’s named <code data-enlighter-language="generic" class="EnlighterJSRAW">B*<\/code><\/code>. Here is what the working tree looks like now:<\/p>\n\n\n\n
A --- B* --- E --- F feature1\n \\     \n  B --- C --- D feature2<\/code><\/pre>\n\n\n\n
You need to catch up with their changes, so you decided to rebase:<\/p>\n\n\n\n
git rebase feature1<\/code><\/pre>\n\n\n\n
And now the bummer – you caught a conflict between <code data-enlighter-language="generic" class="EnlighterJSRAW">B<\/code><\/code> and <code data-enlighter-language="generic" class="EnlighterJSRAW">B<\/code><\/code>* and need to resolve it. Sound familiar?<\/p>\n\n\n\n
Solving the issue with git rebase \u2011\u2011onto<\/em><\/h2>\n\n\n\n
Before blaming your colleague, you need to realize that the issue is not with the change itself. The issue lies in the way standard <code data-enlighter-language="generic" class="EnlighterJSRAW">rebase<\/code><\/code> does its job. In the example above, rebase takes <code data-enlighter-language="generic" class="EnlighterJSRAW">feature1<\/code><\/code> as a starting point and then tries to apply all new commits atop.<\/p>\n\n\n\n
In other words, it takes commit <code data-enlighter-language="generic" class="EnlighterJSRAW">F<\/code><\/code> as a new starting point. Then, it finds the place where both branches have diverged. In our case, it’s commit <code data-enlighter-language="generic" class="EnlighterJSRAW">A<\/code><\/code>. So, <code data-enlighter-language="generic" class="EnlighterJSRAW">rebase<\/code><\/code> takes commits <code data-enlighter-language="generic" class="EnlighterJSRAW">B<\/code><\/code>, <code data-enlighter-language="generic" class="EnlighterJSRAW">C<\/code><\/code>, and <code data-enlighter-language="generic" class="EnlighterJSRAW">D<\/code><\/code>, and one by one, tries to add them on top of commit <code data-enlighter-language="generic" class="EnlighterJSRAW">F<\/code><\/code>. The diff for commit <code data-enlighter-language="generic" class="EnlighterJSRAW">B<\/code><\/code> cannot be applied to existing source tree and thus we need to resolve the conflict.<\/p>\n\n\n\n
Ideally, we want to avoid resolving the conflict and just get the next history tree:<\/p>\n\n\n\n
A --- B* --- E --- F feature1\n                    \\     \n                     C' --- D' feature2<\/code><\/pre>\n\n\n\n
(Notice: <code data-enlighter-language="generic" class="EnlighterJSRAW">C<\/code><\/code>‘ and <code data-enlighter-language="generic" class="EnlighterJSRAW">D<\/code><\/code>‘ have the same changesets as <code data-enlighter-language="generic" class="EnlighterJSRAW">C<\/code><\/code> and <code data-enlighter-language="generic" class="EnlighterJSRAW">D<\/code><\/code> but we updated the naming to reflect changes in <code data-enlighter-language="generic" class="EnlighterJSRAW">SHA<\/code><\/code>)<\/p>\n\n\n\n
So, we want to take commits<code data-enlighter-language="generic" class="EnlighterJSRAW"> C<\/code><\/code> and <code data-enlighter-language="generic" class="EnlighterJSRAW">D<\/code><\/code> and attach them on top of <code data-enlighter-language="generic" class="EnlighterJSRAW">feature1<\/code><\/code>, ignoring the previous history altogether. This can be achieved by git cherry-pick, but it’s a tedious and error-prone job.<\/p>\n\n\n\n
Instead, we can use <code data-enlighter-language="generic" class="EnlighterJSRAW">git rebase \u2011\u2011onto<\/code><\/code>. We need to be on <code data-enlighter-language="generic" class="EnlighterJSRAW">feature2<\/code><\/code> and execute this command:<\/p>\n\n\n\n
git checkout feature2\ngit rebase --onto feature1 B<\/code><\/pre>\n\n\n\n
That means: take all commits after commit <code data-enlighter-language="generic" class="EnlighterJSRAW">B<\/code><\/code> (in our case it will be <code data-enlighter-language="generic" class="EnlighterJSRAW">C<\/code><\/code> and <code data-enlighter-language="generic" class="EnlighterJSRAW">D<\/code><\/code>) and place them atop of <code data-enlighter-language="generic" class="EnlighterJSRAW">feature1<\/code><\/code>.<\/p>\n\n\n\n
After applying this command, we’ll get the desired working tree without the need to resolve the conflict between <code data-enlighter-language="generic" class="EnlighterJSRAW">B<\/code><\/code> and <code data-enlighter-language="generic" class="EnlighterJSRAW">B*.<\/code><\/code> We can still have a conflict if <code data-enlighter-language="generic" class="EnlighterJSRAW">C<\/code><\/code> or <code data-enlighter-language="generic" class="EnlighterJSRAW">D<\/code><\/code> conflicts with <code data-enlighter-language="generic" class="EnlighterJSRAW">B*<\/code><\/code>, <code data-enlighter-language="generic" class="EnlighterJSRAW">E,<\/code><\/code> or <code data-enlighter-language="generic" class="EnlighterJSRAW">F<\/code><\/code>, but that’s a normal case.<\/p>\n\n\n\n
Instead of providing<code data-enlighter-language="generic" class="EnlighterJSRAW"> B<\/code><\/code> as the second argument, we can use relative addressing with <code data-enlighter-language="generic" class="EnlighterJSRAW">HEAD~N<\/code><\/code>. For our example it will be:<\/p>\n\n\n\n
git checkout feature2\ngit rebase \u2011\u2011onto feature1 HEAD~2<\/code><\/pre>\n\n\n\n
That can be read as: take two last commits from my branch and put them atop of <code data-enlighter-language="generic" class="EnlighterJSRAW">feature1<\/code><\/code>.<\/p>\n\n\n\n
Solving the problem of branching from a wrong place<\/h2>\n\n\n\n
There are many cases when you can start your work in the wrong place or for some reason you need to move your commits to a totally different place.<\/p>\n\n\n\n
Here\u2019s a widespread example. You branched off of <code data-enlighter-language="generic" class="EnlighterJSRAW">main<\/code><\/code> branch, but suddenly a product manager tells you that your stuff is critical for production and you need to change the base of your branch to <code data-enlighter-language="generic" class="EnlighterJSRAW">hotfix<\/code><\/code> instead. Here is a commit history:<\/p>\n\n\n\n
       E --- F --- G feature\n       \/\nA --- B main\n \\\n  C --- D hotfix<\/code><\/pre>\n\n\n\n
You need to get the next history instead:<\/p>\n\n\n\n
A --- B main\n \\\n  C --- D hotfix\n         \\\n          E' --- F' --- G' feature<\/code><\/pre>\n\n\n\n
(Notice: <code data-enlighter-language="generic" class="EnlighterJSRAW">E'<\/code><\/code>, <code data-enlighter-language="generic" class="EnlighterJSRAW">F'<\/code><\/code>, and <code data-enlighter-language="generic" class="EnlighterJSRAW">G'<\/code><\/code> have the same changesets as <code data-enlighter-language="generic" class="EnlighterJSRAW">E,<\/code><\/code> <code data-enlighter-language="generic" class="EnlighterJSRAW">F<\/code><\/code>, and <code data-enlighter-language="generic" class="EnlighterJSRAW">G<\/code><\/code> but we updated the naming to reflect changes in <code data-enlighter-language="generic" class="EnlighterJSRAW">SHA<\/code><\/code>)<\/p>\n\n\n\n
If you use regular rebase<\/code>, commit B <\/code>will sneak into hotfix<\/code> branch. In practice, main<\/code> branch can have dozens of other features merged and you would bring all of them into hotfix<\/code>.<\/p>\n\n\n\n
But git rebase \u2011\u2011onto<\/code> does not have this issue. Here is a solution:<\/p>\n\n\n\n
git checkout feature\ngit rebase \u2011\u2011onto hotfix B<\/code><\/pre>\n\n\n\n
or the same with relative addressing:<\/p>\n\n\n\n
git checkout feature\ngit rebase \u2011\u2011onto hotfix HEAD~3<\/code><\/pre>\n\n\n\n
Actually, almost all cases of moving around commits can be handled with <code data-enlighter-language="generic" class="EnlighterJSRAW">\u2011\u2011onto<\/code><\/code> option.<\/p>\n\n\n\n
Dropping commits<\/h2>\n\n\n\n
For the sake of completeness, let’s discuss how to remove commits with \u2011\u2011onto<\/code> option. Here is an example of a working tree:<\/p>\n\n\n\n
A \u2011\u2011\u2011 B \u2011\u2011\u2011 C \u2011\u2011\u2011 D \u2011\u2011\u2011 E  feature<\/code><\/pre>\n\n\n\n
We want to remove commits C<\/code> and D<\/code> to obtain the next commit history:<\/p>\n\n\n\n
A \u2011\u2011\u2011 B \u2011\u2011\u2011 E'  feature<\/code><\/pre>\n\n\n\n
(Notice: E<\/code> and E’ have the same changeset, but E'<\/code> has another SHA<\/code> due to a change in commit history)<\/p>\n\n\n\n
Here is the solution:<\/p>\n\n\n\n
git checkout feature\ngit rebase \u2011\u2011onto B HEAD~1<\/code><\/pre>\n\n\n\n
A word of caution<\/h2>\n\n\n\n
Using rebase<\/code> always has the risk of doing something wrong and losing your commits. If you are still new to this tool, be sure to follow the usual safety measures: keep SHA of the HEAD of your branch before doing rebase or be fluent with using git reflog<\/code>.<\/p>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
As I said, git rebase \u2011\u2011onto<\/code> greatly improved my commit housekeeping experience and removed a lot of pain points I had before. Despite the logic of \u2011\u2011onto<\/code> option being quite simple, it took me some time to find a proper way and practical understanding of how to use it in various scenarios.<\/p>\n\n\n\n
So I hope this article will save you some time and extend your Git tricks collection.<\/p>\n","protected":false},"excerpt":{"rendered":"
A simple tutorial on how to use git rebase –onto to easily move or copy a bunch of commits from one branch atop another<\/p>\n","protected":false},"author":25,"featured_media":15103,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[3],"tags":[],"coauthors":["Sergii Boiko"],"class_list":["post-15104","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development"],"acf":[],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t