Objective
With Git version control tools, we usually pull out the new branch from the main branch for development, create a PR (called pull request) after the development is completed, and let the other small partners help review to determine that the code has no problem and then merge the new branch onto the main branch. But, do you really understand who the two branches in pull request are compared to?
The following is a virtual case description: Assuming the main branch is named "Master", the new branch is called "DevelopBrance1".
Note: The arrows in the diagram refer to the direction of the work advance, rather than the point of submission (the commit point is always directed by the current commit to the parent commit, and here the Arrows are reversed)
The simplest case
, we pull out the new branch developBranch1 from the M1 submission point of the Master Branch Master and then develop on the DevelopBranch1 branch (D1, D2, D3 a total of 3 commits were generated during the development process), and the PR is created after the development is completed. Then, after review, it is merged into the main branch to form a new commit point N. Naturally, the source and target we selected when we created the PR were:
src[developBranch1]-dest[Master]
We expect the PR comparison is the DEVELOPBRANCH1 and master two branches of the latest submission point, PR is actually compared to the DevelopBranch1 D3 submission Point and the Master branch of the M1 The difference between submission points.
Add a bit of complexity
Assuming that there are other small partners working with you now (this is the scene at work), another small partner pulls out the branch DEVELOPBRANCH2 from the M1 submission point of the Master Branch for Development and produces several commits, and has been merged into the master branch before our development is complete:
Now when we create the PR, the source and the target are naturally:
src[developBranch1]-dest[Master]
But at this time, the PR is actually compared with the developBranch1 and master of the two branches of the latest submission point ( developBranch1 D3 submission Point and the Master branch of the M2 submission point )?
Answer: No. Now the PR comparison is actually the DevelopBranch1 D3 submission Point and The master branch of the M1 submission point , and the above simplest case completely no difference!
In fact, the bottom of the PR of this implementation is very reasonable:
when we created the PR, the differences between the two branches were just the content of their own development. Imagine that if you compare the differences between the DEVELOPBRANCH1 D3 submission Point and the M2 submission point of the Master branch in a collaborative development scenario, then we will see the development of other small partners at the same time, would you like to think that this is not a reaction to the "latest work progress"? Don't you just look at the code of a little buddy? Well, imagine if a lot of people developed at the same time, when we submit our own code, with a lot of other small partners of the code, you will not find your own development of code and crazy?
"The latest work progress" doubts still in it? Here's the answer.
How does git reflect the latest work progress?
In fact, when git merges different branches, it automatically takes their union to maintain the final work progress. Take it that if there is no conflict between the D3 submission point of the DEVELOPBRANCH1 and the O2 submission point of the DEVELOPBRANCH2, the development of both will eventually be reflected in the M3 (of course, there is a conflict that requires manual resolution).
Now there is another question, what is the principle of PR comparison?
The PR comparison is:
The difference between the closest commit point of the source branch and the most recent public parent submission node of the source and destination branches . In the second picture, you can see that the source branch is DEVELOPBRANCH1, the target branch is master, and the most recent public parent commit node for the two branches is M1, so the final comparison is the last commit point D3 and M1 of the source branch .
Explore the strong readers can also try to separate the different branches as the source and target of PR, observe the difference in PR output to deepen the impression.
Postscript
Other more complex branch PR principles are similar, but need to be analyzed in conjunction with more complex merge strategies. If there are omissions in the text, please add.
Well, it's time to review and review the principles of the two-node nearest common parent node ^_^
Better article recommendation
zhuanlan.zhihu.com/p/26227256