{"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, 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 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 feature1<\/code><\/code>, that was created by your colleague. Your goal is to add some new stuff to it. You happily branched off of feature1<\/code><\/code> and implemented new functionality in commits C<\/code><\/code> and 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 feature1<\/code><\/code>. But they also like to use rebase, so they modified commit B<\/code><\/code> a bit. On the diagram below, it’s named 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 B<\/code><\/code> and 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 rebase<\/code><\/code> does its job. In the example above, rebase takes 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 F<\/code><\/code> as a new starting point. Then, it finds the place where both branches have diverged. In our case, it’s commit A<\/code><\/code>. So, rebase<\/code><\/code> takes commits B<\/code><\/code>, C<\/code><\/code>, and D<\/code><\/code>, and one by one, tries to add them on top of commit F<\/code><\/code>. The diff for commit 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: C<\/code><\/code>‘ and D<\/code><\/code>‘ have the same changesets as C<\/code><\/code> and D<\/code><\/code> but we updated the naming to reflect changes in SHA<\/code><\/code>)<\/p>\n\n\n\n
So, we want to take commits C<\/code><\/code> and D<\/code><\/code> and attach them on top of 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 git rebase \u2011\u2011onto<\/code><\/code>. We need to be on 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 B<\/code><\/code> (in our case it will be C<\/code><\/code> and D<\/code><\/code>) and place them atop of 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 B<\/code><\/code> and B*.<\/code><\/code> We can still have a conflict if C<\/code><\/code> or D<\/code><\/code> conflicts with B*<\/code><\/code>, E,<\/code><\/code> or F<\/code><\/code>, but that’s a normal case.<\/p>\n\n\n\n
Instead of providing B<\/code><\/code> as the second argument, we can use relative addressing with 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 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 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 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: E'<\/code><\/code>, F'<\/code><\/code>, and G'<\/code><\/code> have the same changesets as E,<\/code><\/code> F<\/code><\/code>, and G<\/code><\/code> but we updated the naming to reflect changes in 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 \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":[],"categories_data":[{"name":"Engineering","link":"https:\/\/railsware.com\/blog?category=development"}],"post_thumbnails":"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2022\/08\/Git-onto_Featured-image_2400x1260-1024x538.jpg","amp_enabled":true,"_links":{"self":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/15104","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/users\/25"}],"replies":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/comments?post=15104"}],"version-history":[{"count":32,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/15104\/revisions"}],"predecessor-version":[{"id":15650,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/15104\/revisions\/15650"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media\/15103"}],"wp:attachment":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media?parent=15104"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/categories?post=15104"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/tags?post=15104"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/coauthors?post=15104"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}