Three operations of git merge merge, squash merge, and rebase merge

Three operations of git merge merge, squash merge, and rebase merge

For example:
Suppose a new branch dev is pulled out at point B of the master branch, after a period of development:

  • There are two new commits M1 and M2 on the master branch
  • There are three commits D1, D2, and D3 on the dev branch

As shown below:

img

image.png

Now that we have completed the development and testing of the dev branch, we need to merge the dev branch back into the master branch.

  1. merge

This is the most basic merge, which is to copy the submission history intact, including the complete submission history.

$ git checkout master
$ git merge dev

img

image.png

At this time, a merge commit (D4') will also be produced. This merge commit does not contain any code changes, but contains several commit lists (D1, D2 and D3) on the dev branch. Check the git commit history (git log) to see all these commit histories.

  1. squash merge:

According to the literal meaning, this operation completes the compressed submission; what problem does it solve? Since the development work is performed on the dev branch, there are some small submissions, or submissions that correct previous errors. Submission does not need to be displayed separately for the entire project, otherwise the submission history of the project will be too complicated; so for this reason, we can merge all submissions on dev into one submission; and then submit it to the trunk.

$ git checkout master
$ git merge --squash dev

img

image.png

In this example, we merge the changes from D1, D2 and D3 into one D.

Note that squash merge does not generate commits for you, it just merges all changes and puts them in local files, requiring you to manually execute git commit operation again; pay attention again at this time, because you want you to commit manually, and also That is to say, this commit was generated by you, not by the developers on the original dev branch, and the committer itself has changed. It can also be understood in this way, that is, you port all the code changes on the dev branch to the master branch at one time.

  1. rebase merge

Since squash merge will change the author information of the submitter, this is a big problem, and it is not easy to deal with later problem tracing (of course, the squash merge operation can also be performed by the owner of the branch dev to solve some problems), rebase merge can be retained The submitted author information can be merged with the commit history at the same time, which perfectly solves the above problem.

$ git checkout dev
$ git rebase -i master
$ git checkout master
$ git merge dev

The rebase merge is completed in two steps:
the first step: execute the rebase operation, the result is that it seems that the dev branch is pulled from M2 instead of B, and then use the -i parameter to manually adjust the commit history, whether to merge or how to merge . For example, the following rebase -i command will pop up a text edit box:

pick <D1> Message for commit #1
pick <D2> Message for commit #2
pick <D3> Message for commit #3

Assuming that D2 is a typofix to D1, so we don't need to explicitly point it out, we change D2 to fixup:

pick <D1> Message for commit #1
fixup <D2> Message for commit #2
pick <D3> Message for commit #3

The state after rebase becomes:

img

image.png

D1' is the merger of D1 and D2.

Step 2: Execute the merge operation again to merge the dev branch into the master branch:

img

image.png

Note: There may be conflicts when executing rebase. At this time, you need to manually resolve the conflicts, and then execute the (git add) command; after all conflicts are resolved, you do not need to execute the (git commit) command at this time, but Run the (git rebase --continue) command until the rebase is complete; if you want to give up the rebase operation in the middle, you can run the (git rebase --abort) command to return to the state before the rebase.

Author: CodingCode
Link: https://www.jianshu.com/p/ff1877c5864e
Source: Jianshu
The copyright belongs to the author. For commercial reprint, please contact the author for authorization, for non-commercial reprint, please indicate the source.

Guess you like

Origin blog.csdn.net/stallion5632/article/details/129093181