git rebase

Definition

Rebasing means to move or combine a series of commits to a new base commit. In other words, it changes the basis of the current branch from one commit to another, making it look like the branch has been created from another commit. This is done by executing the git rebase command. Take into account that even if the branch looks the same, it is built up of wholly new commits.

Usage of the git rebase command

Firstly, we need this command for maintaining a linear project history. For example, the master branch progresses after you start to work on a feature branch. You need the recent updates of the master branch in your feature branch, but the history of the master branch must remain clean. We need a clear history when executing Git operations to track down regressions. Find more information about the usage of git rebase below:

The inadmissibility of rebasing public history

Never rebase commits after publishing them in public history. As in the case of amending and resetting, it will cause problems for team collaboration. If you do it, the old commit will be replaced by a new one and it will look as though part of your project has disappeared.

The difference between Git rebase standard and Git rebase interactive.

There are two modes of git rebase command: standard and interactive. In standard mode git rebase will automatically apply the commits in the current working branch to the passed branch’s head. The current branch will be rebased onto <code><base></code>. This can be different kinds of commit references, such as a tag, an ID, a branch name and so on.

git rebase command

git rebase <base>

In interactive mode git rebase is executed with the -i flag, which stands for “interactive”. The advantage of rebasing in interactive mode is changing the individual commits in the process, without having to move all the commits to the new base. Due to this mode, you can clean the history by removing and changing the existing sequence of commits.

Running the following command will open an editor:

git rebase -i

git rebase --interactive <base>

In this editor enter the commands given below for each commit that must be rebased. Git will start to replay commits and apply the rebase commands, after determining the commands for each commit.

git rebase example

pick 11a1456 some old commit
pick a23db19 Adds new feature
# Rebase 31d332c..a23db19 onto 31d332c (9 commands)
#
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit

Interactive rebase commands

During an interactive rebase, you can use the following commands for each commit in the todo list:

• drop: Discards the commit from the final combined commit block during replay.
• pick: Keeps the commit as is, without editing the message or content, leaving it as an individual commit in the branch history.
• exec: Allows running a command line shell script on each marked commit during replay.

Git recap

One of the interactive rebasing advantages is that it allows developers not to worry about the messiness of the project history, as they can later go back and clean it up. So, many developers use this tool to make the feature branch history cleaner before merging it into the master branch. Cleaning up a branch means removing meaningless or dead and gone commits. As a result, developers have a well-planned history and can easily understand what commits have been done.

Configuration options

There exist some rebase options that are set with the help of the git config command. These options alter the behavior and output of git rebase.

• rebase.stat: by default a false boolean, which toggles display of visual diffstat content showing changes since the last rebase.
• rebase.autoSquash: A boolean value toggling the --autosquash behavior.
• rebase.missingCommitsCheck: It can be set to multiple values changing the rebase behavior around missing commits. | warn | Warning output is printed in interactive mode and warns about removed commits. | |---|---| | error | The rebase is stopped and removed commit warning messages are printed. | | ignore | The default option, which ignores any missing commit warnings. |
• rebase.instructionFormat: A string in git log format used for formatting interactive rebase display.

Advanced rebase application

The git rebase can be passed to the --onto command line argument, in which case the command expands to the following:

git rebase --onto

git rebase --onto <newbase> <oldbase> <branch>

The --onto command provides advanced rebase application as it allows passing specific refs as the rebase base commits.

Let’s see its behavior on an example:

git rebase --onto example

o---o---o---o---o master
 \
 o---o---o---o---o featureX
 \
 o---o---o featureY

Although featureY was originally based on featureX, it is independent of featureX's changes and can be rebased directly onto master. This command replays the commits from featureY onto master, effectively detaching featureY from featureX.

git rebase --onto command

git rebase --onto master featureX featureY

FeatureX is the <code><oldbase></code>, master is the <code><newbase></code>, and featureY is the branch being rebased. Here is the output:

git rebase usage

o---o---o featureY
 /
 o---o---o---o---o master
 \
 o---o---o---o---o featureX

The dangers of rebasing

The first danger of using the git rebase command is that it can cause more merge conflicts during a rebasing process, especially in cases when you have a long-lived branch that has diverged from master. Sooner or later you may decide to rebase against the master, which may contain some new commits which the changes of your branch may conflict with. The solution to the situation described above is rebasing the branch against the master more often and making more frequent commits. In order to continue or abort the rebase while resolving conflicts, you can use the --continue and --abort arguments with the git rebase. Another more serious risk is that some commits may be lost from interactive history rewriting. Running rebase in interactive mode with some subcommands like squash or drop remove commits from the immediate log of the branch. It may seem as though the commits are removed permanently. The solution is the git reflog, which allows these commits to be restored and you can undo the entire rebase.

Recovering from upstream rebase

In case another user has rebased and force-pushed to the branch that you’re committing to, a git pull will then overwrite any commit you have based off that previous branch with the force-pushed tip. Git rebase allows you to use the reflog of the remote branch. There you can find a ref before it was rebased. Then you can rebase your branch against that remote ref with the --onto option.

Practice

What are the correct statements about the `git rebase` command as described in the W3Docs Git Tutorial?

`git rebase` changes the base of the current branch to a different commit, creating entirely new commits in the process.The `git rebase` command is used for maintaining a linear project history and a clean master branch history.Rebasing public history commits is recommended for better team collaboration.`git rebase` has two modes: standard and interactive, with interactive mode allowing individual commit changes during the process.The `--onto` option of `git rebase` is used for applying specific refs as the rebase tips.Using `git rebase` in interactive mode can cause merge conflicts and potential loss of commits, which can be recovered using `git reflog`.