The main points of this article are first written in the front.
- develop on the same branch with fewer changes per commit, it is recommended to use
- it is recommended to use
rebasewhen merging from a public branch to a personal feature branch
- when merging from different branches with many change records,
- To merge from a personal topic branch to a public branch, you should use
merge, don’t use
rebaseinstead of git merge
If you are used to using the default
git merge operation, this article may help you.
git rebase instead of
git merge, you can keep a clearer change history and quickly troubleshoot problems based on that history.
Introduction to git merge
Example of a
git merge operation.
The above action is to
merge the latest content of
master branch to
feature branch. When the operation succeeds, a
Merge commit will be automatically generated on the
The above are operations on different branches. Examples of operations on the same branch.
- Advantages of
merge: simple, easy and fast, a
- Disadvantage of
merge: automatically created
Merge commitleads to a very complex change tree and change history, which is difficult to understand when analyzing file change records
Introduction to git rebase
rewrites the project history by creating a new
commit for each commit in the original branch.
Example of a
git rebase operation.
The above operation will merge the contents of the master branch into the feature branch. After the operation succeeds, all the change history is updated to the latest, and no additional commits are generated.
These are operations on different branches. The difference between operating on the same branch and
merge is in the last step. Example.
This completes a rebase operation on the same branch. When a conflict arises, you will need to continue with
git rebase and then resolve the conflict.
- Advantages of
rebase: more concise project history, no merge commit
- Disadvantage of
rebase: When there are a lot of changes, you have to keep resolving conflicts when there is a high probability of conflicts, because you have to rebase each change one by one.
Summary: git merge and git rebase usage suggestions
Compare the directory tree structure of the two operations.
Summary and recommendations.
- On the same branch, it is recommended to use
rebasewhen there are few changes per commit
- Merge from a public branch to a personal feature branch,
- To merge from a personal feature branch to a public branch, you should use
mergeand don’t use the
- It is recommended to use
mergewhen merging different branches with a large number of change records
Some tips on how to do git rebase
Using TortoiseGit for rebase operations
Right-click and select
Sync, set the pull method to
Get, then Change Base (English equivalent path:
Git Sync ->
Fecth & Rebase). As shown in the image.
gitlab turns on the fast-forward merge option
Settings - General - Merge request - Merge method and select the
Fast-forward merge option.
- No automatically created
- Use only the Fast-forward merges policy
- When a conflict arises, you can use the
rebasevariable base method
git rebase –onto
base: a branch name (representing the HEAD of this branch), or a commit_id (this id is not on
from: a branch name (this branch has a common ancestor commit with
to), or a commit_id (this id is on
to: a branch name
What the command does.
- first executes
git checkoutto switch to the
- writes the commits in the range from
to(HEAD)to a temporary file. If
fromis the branch name, find
commit, the common ancestor of
to, and write the commits in the range from
to(HEAD)to a temporary file.
- Force a reset (git reset -hard) of the current branch to
- From the list of commits in the temporary file in 2, recommit the commits to the reset branch, one by one, in order
- If a commit is encountered that is already contained in a branch, the commit is skipped.
- If you encounter a conflict during the commit process, the diff process is suspended. After resolving the conflict, the user can either continue the rebase operation with
git rebase --continue, skip the commit with
git rebase --skip, or terminate the rebase operation with
git rebase --abortand switch to the branch before the rebase.
- When the operation is finished, the current branch is
git rebase -i Interactive Rebase
rebase gives you the opportunity to change these
commits when pushing commits to the remote branch. To use interactive rebase, you need to add the
-i (interactive) option. Example.
The above action will open a text editor that lists all commits that will be moved. Example.
pick at the beginning of each line indicates the type of directive for that commit. git provides the following directive types:
- pick: keeps the commit (abbreviation:p)
- reword: keep the commit, but I need to change the commit’s comments (abbreviation:r)
- edit: keep the commit, but I want to stop and change the commit (not just the comments) (abbreviation:e)
- squash: merge this commit with the previous one (abbreviation:s)
- fixup: merge this commit with the previous commit, but I don’t want to keep the commit’s comment information (abbreviation:f)
- exec: execute shell command (abbreviation:x)
- drop: I want to discard the commit (abbreviation:d)
By changing the pick command or reordering entries, you can make the branch history change to the result you want.
For example, if the second commit fixes a minor issue in the first commit, you can condense them into a single commit using the following fixup command.
Another example is a feature that was committed multiple times during local development. Finally, you want to compress them into a single commit.
When you save and close the file, Git will perform a rebase based on the modified instructions.
Undo rebase base change operation
git reflog allows you to see the reference log of all operations. Using the
git reset command, you can roll back to any historical state based on the reference log.
TortoiseGit is also relatively simple: right mouse button ->
Show Reference Records and you can do it visually in the popup list of reference records.
rebase and git hooks
In the previous example, you may have noticed the use of the
rebase uses an item-by-item
commit approach when executing the
pick command, when there is a
git hook in the repository, the hook will be executed for every operation, making it very slow, but the
rebase process hook doesn’t make much sense. Adding the
-no-verify argument can bypass the
git hook execution. So the recommended conclusion is.
git hooksare present, the rebase operation is recommended to add the
-no-verifyargument to bypass the execution of the hook.