[WP] 01.05.2023 | git-rebase

 

fig 1.1 git rebase scheme<atlassian.com>

This post is about git rebase command. Rebase along with merge is a way to join main branch and feature branch. Merge is about forward moving change record. On the other hand rebase comes with amazing history re-writing features. In simple words rebase operation is about moving or combining a sequence of commits to a new base commit. To rebase current branch simply type rebase and put a commit_id as an argument. #git rebase <base commit id>. Changing a base of your branch looks as if you started this branch from totally different commit than origin. Under the hood git creates whole new commits and apply them to base commit specified within command. Let’s make it clear the branch starts from a different commit looks the same but contains brand new commits. It may look senseless but rebase have crutial meaning if it comes to maintain a linear commits history within your repo.

One good example of git rebase application is the following situation:

• You are working on a separate feature branch 
• Since youve been working there were several updates to main branch. 
• You need to keep your commit history clean. 

It is a good oportunity to use git rebase. Very often rebase command is used to polish a feature branch before merge it into the main codebase. (e.g. squash insignificant commits, delete obsolete commits).

Git rebase comes in two modes: manual & interactive. Interactive mode is triggered with -i or –interactive flag and allows to alter, remove and split individual commits. You may say that it is git –amend on steroids :). During interacive hisory rewriting several additional rebase commands could be used: p-pick, r-reword, e-edit, s-squash, f-fixup, e-exec and d-drop.The following properties may be used along rebase: stat- What changed since last rebase?, autoSquash- toggles –autosquash behaviour, missingCommitsCheck – warn, error, ignore behaviour. instructionFormat- pass a format string for formating rebase display.

3 way merge together with merge commit is a result of git merge operation. Git rebase lets fast forward merge and maintain clean history.Clean history of official records looks good and is clear to understand and maintain. What is more one of the main benefits of clean history is that it helps investigate introduction of a regression using git bisect. Integration of your feature may be done in two ways 1.direct merge or 2. rebase and then merge.

At the end I would like to mention several things about a rebase that may go wrong. Firstly some conflicts may emerge. We may apply –continue and –abort flags to deal with conflicts to some extent. Secondly the big issue is lost commits. Some commits may be permanently gone due to rebase /interactive history rewrite. If any commits are lost it is advised to use git reflog to restore them. The good rule of thumb is to never rebase commits once they have been pushed to remote public repository. 

Last but not least it it is important not to execute history rewriting in connection with –force pushing. This kind of action has capability to overwirte other remote user work once they execute pull command.

cheers
g-marcin