Objective
I believe most of the friends who use Git will meet the same question, and also search for a lot of information from the Internet. So, why do I have to write this article? Because I want to try to explain the problem from their own perspective, if you can give everyone a flash of inspiration, it is good. Estimated points in the friends also have a certain understanding of the merge and rebase, so I will not waste space to detail the merge and rebase, let us go straight into the topic.
Merge and rebase the difference merge
Now suppose we have a master branch master and a development branch Deve, the warehouse history is like this:
Now if you are on the master branch git merge deve
: Git will automatically merge with the latest commits and two branches based on the common ancestor of the two branches, i.e. the e381a81
commit 8ab7cff
, and 696398a
then generate a new commit for the modified content in the merge, that is, the78941cb
Rebase
What is the situation with rebase? is also an initial warehouse history map:
If it is on the master branch git rebase deve
: Git 3311ba0
Extracts the changes on the Master branch (the current branch) from the common ancestor of the two branches, i.e. 85841be
,, a016f64
and e53ec51
then points the master branch to the latest commit of Deve (the target Branch) 35b6708
, and then apply the changes that you just extracted to the later commit. The operation discards the commit that was fetched on the master branch, and does not generate a commit of the merge modification like the merge, which is equivalent to copying the changes on the Master branch (the current branch) on the Deve branch (the target branch), The version history is like this when the operation is complete:
You can see that the master branch has submitted its own three commits since the latest submission of the Deve branch 35b6708
(because it was extracted and then re-submitted, so the hash code of the commit is 85841be
a016f64
e53ec51
different from the above,
Rebase-i
The Rebase action plus -i
option allows you to see the extracted commit information more visually.
Still rebase the Deve branch on the master branch, but this time add the -i
option, that is git rebase -i deve
, then we can get such a text message box
The information in the A-zone explains which commit records (and) are extracted from this rebase operation f9a7673
edb2ba2
, followed by which commit () is connected to the target branch 9c86a5c
. Can be modified to other commands according to the command instructions in area B pick
, additional operations on the extracted commit
Section B describes the commands that can be selected for this rebase operation.
:wq
after the exit is saved, the commit is processed and rebase in accordance with the command just set in the A zone.
Differences in conflict handling strategies
The merge will stop immediately after encountering the conflict, wait for the conflict to be resolved manually and resubmit the commit before you can merge again
Rebase the current operation is paused after encountering the conflict, the developer can choose to resolve the conflict manually, then git rebase --continue
continue, or --skip
skip (note that the modification of the current branch in this operation will directly overwrite the conflicting portion of the target branch), or --abort
stop the rebase operation directly
merge --no-ff
And
merge --ff-only
The difference
The above description of the merge is based on its default action --no-ff
( git merge xxx
= git merge --no-ff xxx
), but there is a common option for merge --ff-only
, what is the difference between the two?
--no-ff
is the default operation of the merge, the three parties merge and commit the changes, and the --ff-only
current branch can be determined to quickly merge according to the target branch, as follows
At this point, the Deve branch can be quickly merged with the master branch.
On the Deve branch git merge --ff-only master
, you get the version history map after the merge is completed
You can see that --ff-only
the generated history is very similar to rebase, but --ff-only
it is still a merge operation, but Rebase is not merging, just extracting the changes to the target branch.
Summary: Choose Merge or Rebase?
Merge is a merge operation that merges the changes of two branches and commits the modified content in the merge with the default action
The commit history of merge faithfully records what actually happened and focuses on the actual commit history
Rebase does not perform a merge operation, but only extracts the current branch's modifications and copies it after the latest commit of the target branch
Rebase's submission history reflects what has happened during the project and focuses on the development process
Merge and rebase are very powerful branch integration commands, no pros and cons, which should be determined by the development needs of the project and the team
Merge and Rebase also have many powerful options that you can use to git help <command>
view
Finally: some points of attention
When using merge, you should consider using the --no-ff
default action to generate a merge record that is not friendly to the review commit history, or how to use --ff-only
The rebase operation discards the commit committed by the current branch, so do not perform rebase operations on a branch that has been push to remote and others are collaborating on development
When synchronizing with a remote warehouse, two actions are performed by default using the git fetch + git merge --no-ff
pull command, and you can --rebase
change the fetch merge operation to a rebase operation by adding a command, or just ' git fetch remotename ' before thinking about what kind of consolidation to take Strategygit merge(or rebase) origin/master
When developing and commit, notice where you are on this branch
When there is a modification not commit, can not do rebase operation, at this time, you may consider the first with the git stash
command staging
Reference:
Chat git merge and git rebase the difference