Git Rebase

git

https://git-scm.com/book/en/v2/Git-Branching-Rebasing
https://www.atlassian.com/git/tutorials/rewriting-history
https://www.atlassian.com/git/tutorials/merging-vs-rebasing
https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase
https://stackoverflow.com/questions/804115/when-do-you-use-git-rebase-instead-of-git-merge
https://nathanleclaire.com/blog/2014/09/14/dont-be-scared-of-git-rebase/
https://www.git-tower.com/blog/understanding-rebase-merge-in-git/
https://www.git-tower.com/learn/git/faq/rebase
https://benmarshall.me/git-rebase/
https://help.github.com/articles/using-git-rebase-on-the-command-line/

What is rebasing?

A popular alternative to merging is rebasing. Rebasing starts with the common ancestor of two branches: the one you’re on and the one you’re rebasing onto. Then, the diffs resulting from each commit of your current branch are saved to temporary files, and the current branch gets reset to the same commit as that of the branch you are rebasing onto. Last but not least, all changes get applied to the branch you are rebasing onto.

This process essentially rewrites a project’s history by replaying all changes committed on one branch to another one, leading to cleaner application of commits on a remote branch and a linear history.

git checkout test
git rebase master

Consider a scenario where the 'experiment' branch has the change C4, and the master branch has change C3, and they diverged at change C2.

You can take the patch of the change that was introduced in C4 and reapply it on top of C3. In Git, this is called rebasing. With the rebase command, you can take all the changes that were committed on one branch and replay them on another one.

git checkout experiment
git rebase master

It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn. I think the end result of this is that the experiment branch now contains the changes from the master branch with all the changes that were previously done on the experiment branch.

At this point, you can go back to the master branch and do a fast-forward merge.

git checkout master
git merge experiment

Now, the snapshot pointed to by C4' is exactly the same as the one that was pointed to by C5 in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.

Often, you’ll do this to make sure your commits apply cleanly on a remote branch – perhaps in a project to which you’re trying to contribute but that you don’t maintain. In this case, you’d do your work in a branch and then rebase your work onto origin/master when you were ready to submit your patches to the main project. That way, the maintainer doesn’t have to do any integration work – just a fast-forward or a clean apply.

Note that the snapshot pointed to by the final commit you end up with, whether it’s the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot – it’s only the history that is different. Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together.

Continue on https://git-scm.com/book/en/v2/Git-Branching-Rebasing from "More Interesting Rebases"

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License