Git Rebase Walk Through
Assume that you have been working on your own branch for a long time, and that the parent branch of your branch has had significant new changes that you want to be on your branch too. You have two options available to you when using Git.
First, you can merge the parent branch to your branch. The first problem with this solution is that you may have conflicts of changes that you did not implement, and you may need to fully understand these new changes to resolve the conflicts. The second problem is the sheer number of changes on the parent branch could be huge and overwhelming to merge. And the third problem is that the version tree with become more complicated.
As a result, Git has another merge option called rebase. The rebase command will basically move your branch onto the latest (HEAD) version of the parent branch. Thus only your changes on your old branch will be individually made off a new branch (on the same branch name) starting on the HEAD of the parent branch.
Here are the basic steps for rebasing a Git branch.
First, go to your branch's parent branch and do a Git pull, so that you guarantee your changes are off of the latest version from the remote repository to minimize future conflicts.
Second, go to your branch that you want to rebase and do a Git pull too, just to guarantee that you rebasing your latest changes too.
Third, run the rebase command with the optional interactive argument.
git rebase -i|
With interactive turned on, an editor will open listing all the SHAs that will be re-applied on a new branch from the parentís branch. Verify these are the correct SHAs on your branch that are moving. You now have two rebase options. First, you can create the same number of SHAs on the new branch by not making any changes in the editor. Or, if you only want to forcefully create a single SHA of all of your original changes (SHAs) on the new branch, you can "pick" the latest or top SHA and change all the other SHAs as "squash" in the editor. This will squash all the SHAs into a single new SHA. Next, save and exit the editor.
The Git rebase command will now create the new branch and re-implement each SHA (individually or squashed as a single SHA) on the new branch. If there are any conflicts, the command will report an error and stop. If there are no conflicts or after the conflicts are resolved (files fixed, added, and committed) by using the "git rebase --continue" command (versus the "git rebase --abort" command), the old branch will be removed and only the new branch using the old branch name will remain.
Finally, do not forget to push your changes to the remote repository.
by Phil for Humanity