git rebase

Git rebase

Definition #

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 #

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 maintain clean. We need a clear history while executing Git operations to explore the introduction of a regression. 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 appear as 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 <base> . This can be different kinds of commit references, as a tag, an ID, a branch name and so on.

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 --interactive <base>

In this editor enter the commands given below for each commit that must be rebased. Git will start to playback commits and apply the rebase commands, after determining the commands for each commit. （在此编辑器中，为必须重新设置基础的每个提交输入下面给出的命令。 Git将开始播放提交并应用rebase命令， 在为每个提交确定命令之后。）

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

Additional rebase commits #

The git rebase has some command options such as:

• git rebase – d. Using this option will discard the commit from the final combined commit block during playback. （- git rebase – d.使用此选项将在播放期间丢弃最终组合提交块中的提交。）

• git rebase – p, which doesn’t edit the message or the content of the commit remaining an individual commit in the branch history. （- git rebase – p ，不编辑消息或提交内容，保留分支历史记录中的单个提交。）

• git rebase – x, which allows to run a command line shell script on each marked commit during playback. （- git rebase – x ，允许在播放期间对每个标记的提交运行命令行shell脚本。）

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 commit. These options give another look and sense to the git rebase.

• rebase.stat: by default a false boolean, which toggles display of visual diffstat content showing changes since the last debase.

• 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 <newbase> <oldbase>

The –onto command provides advanced rebase application as it allows passing specific refs as the rebase tips. （–onto命令提供高级rebase应用程序，因为它允许传递特定的ref作为rebase提示。）

Let’s see its behavior on an example:

o---o---o---o---o master
\
o---o---o---o---o featureX
（o---o---o---o---o功能X）
\
o---o---o featureY

Although featureY is based on featureX, it is independent from any changes in featureX and could be branched off master. （虽然featureY基于featureX ，但它独立于featureX的任何更改，并且可以从master分支。）

git rebase --onto master featureX featureY

FeatureX is the <oldbase>. master is the <newbase> and featureY is reference for what <newbase> HEAD will point to. Here is the output:

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

The dangers of rebasing #

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 durable branch strayed 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 make more periodic commits. In order to advance or reset the rebase while copying with conflicts, you can use the –continue and –abort arguments with the git rebase. Another more serious alarm 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 by the help of which these commits can be restored and you can undo the entire rebase.

Recovering from upstream 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 overwrites any commit you have based off that previous branch with the force pushed tip.Git rebase allows you to get 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.