Git Rebasing
External
- https://git-scm.com/book/en/v2/Git-Branching-Rebasing
- https://www.atlassian.com/git/tutorials/merging-vs-rebasing
Internal
Overview
Rebasing is one of the two main ways to integrate changes from a branch into another. The other way is merging.
Rebasing works as follows: the operation goes to the common ancestor of the head branch (the branch you are on) and base branch (the branch you're rebasing into), getting the diff introduced by each head branch commit, saving these diffs into temporary files, resetting the head branch to the same commit as the base branch, and the finally applying each change in turn. Intuitively, is equivalent with shifting and morphing each commit of the head branch, after the common ancestor, in top of the base branch. This modification allows us to merge the head branch into the base branch without having to create a merge commit - the base branch can simply be fast forwarded with the commits from the head branch.
Rebasing rewrites history, by removing the commits that are being rebased and creating new, equivalent ones. See Merge by Rebasing below.
Merging two branches as described above is the main use case for the rebase. However, rebase can also be used when only one branch is involved to modify the message of the last commit, or even arbitrary commits, reorder commits, delete commits or coalesce several logically-related commits into one commit (squash commits).
Rewriting History
Rebasing removes the commits that are being rebased and creating new, equivalent ones.
Also see:
Practical Use Cases
Merge by Rebasing
One might to "shift" the head branch in preparation of a merge of the head branch into the base brach. The result of the operation is that all commits applied on the head branch are shifted at the top of the base branch - a side effect is that the commits are modified in the process (the history is rewritten). The advantage of doing that is that when the merge occurs, is a simple fast forward merge, and no additional merge commit is created - the changes required by the merge are already worked into the commits that are rebased.
TODO: research. Before doing that, don't we want to pull --rebase the base branch?
git checkout <head-branch> git rebase <base-branch>
At the end of this step, the branches still exist, but now the head branch can be merged into the base brach by fast forwarding it - a merge commit is not required.
To merge, we just simply fast forward:
git checkout <base-branch> git merge <head-branch>
What to Do if the Base Branch was itself Rebased
It is not uncommon to attempt to merge into a base branch only to find out that the base branch itself was rebased, so the commits we were relying on were rewritten. It is still possible to rebase/merge with minimum of effort, without to have to wade through a massive amount of conflicts. The procedure is described below:
Move a Branch Forward
It is sometimes desirable to move an entire branch forward, "in top" of its base branch, to take advantage of the latest developments on the base branch, without necessarily merging. For that, the simplest procedure is to find the common ancestor, then use the following syntax, assuming we are on the head branch we want to move forward:
git rebase --onto <base-branch> --fork-point <common-ancestor-commit>
Immediately after that, the head branch must be force-pushed:
git push --force
otherwise we get this:
On branch topic/... Your branch and 'origin/topic/...' have diverged, and have 1 and 2 different commits each, respectively. (use "git pull" to merge the remote branch into yours)
Squashing Commits
Applying Extra Changes to the Last Commit
Update the Commit Message of a Specific Commit
Reordering Commits
The order of commits on a branch can be changed by initiating an interactive rebase, and reordering the commits with the help of the editor.
Rebasing Merge Commits
By default, a rebase will drop merge commits from the TODO list, and put the rebased commits into a single linear branch.