Git Cherry-pick, usually called cherry picking. This is an operation of Git, which is used to transfer part of the code from one branch to another.
Under normal circumstances, we use the git mergesame method to merge the code of the two branches. This situation applies to all code changes that we need in another branch (including the base code before the branch is created).
Another situation is that you only need some code changes (a few commits), then you can use Cherry pick.
Here is an example to explain the operation steps:
There are two development teams, A and B, working on the same project, and the development side receives a version requirement. It is assumed that it needs to go online on January 21, 2020. A is for financial-related functions, and B is for service-related functions.
Team A entered the development ahead of schedule due to ample time and created a new branch from dev on January 8th, named dev-finance-20210121.
After a meal operation, on January 12, Team A completed the development, so the dev-finance-20210121 branch was merged into the dev branch through the merge method.
On January 13, at this time, Team B was busy with the things at hand and entered the development stage, so it created another branch from dev and named it dev-service-20210121. Note: The branch created at this time contains the content submitted by Team A.
On January 15th, the B team also completed the development, so the dev-service-20210121 branch was merged into the dev branch through the merge method.
After the development on both sides is completed, just wait for the test to be correct.
However, suddenly on January 16, Team A couldn't go online due to the delay of the relying party. The product agreed and needed to be rolled back! And the function of B team goes online normally.
Then, you have to roll back the dev code as a whole to the undeveloped version. duang duang duang, the rollback is successful!
At this point, on the dev branch, the code submitted by the A team is missing, no problem. But without the code submitted by Team B, how can this work? B has to go online.
Merge the dev-service-20210121 branch to the dev branch again through the merge method?
Um, no, the dev-service-20210121 branch was created after A team submitted it, and it contains the code submitted by A, which will bring the content submitted by team A as a whole.
If you rebuild the branch, and then copy the previous changes, piece by piece of code, it will not work, it will be too troublesome, and it will be easy to miss.
How to do it? Hey, at this time our Cherry pick will work.
It is possible to directly pick the cherry pick of the dev-service-20210121 branch to the dev branch, but the development has to be changed during the testing phase. Is it Cherry pick every time I change it? This is troublesome.
At this point, the new branch + Cherry pick method is used, and then the merge method can be used.
Therefore, on January 17, Team B created a new branch again from dev, named dev-service-20210121-new. Note: The branch created at this time does not contain the content submitted by Team A, because the dev branch has been rolled back.
Using the Cherry pick method, Team B merged the part submitted on the dev-service-20210121 branch to the dev-service-20210121-new branch.
Then merge the dev-service-20210121-new branch to the dev branch. At this time, it is realized that the dev branch contains only the content submitted by the B team.
Abandon the dev-service-20210121 branch, and then the B team will fix the bug on the dev-service-20210121-new branch. After fixing the bug, when it merges to the dev branch, how to merge and merge.
How to do it? Please see the following example in idea:
1. Right-click the module name and switch the project to the new branch dev-service-20210121-new
2. Open git Log, find the git Log window of the module, select select, and query the original dev-service-20210121 branch
3. From the submission history, select the submission content that needs to be merged, and right click to Cherry pick. (If there is a conflict, it means that after you switch to the new branch, you have changed the code locally but did not submit it. At this time, you need to resolve the conflict)
4. In this way, the submissions required by the original dev-service-20210121 branch are merged locally. Of course, this is only locally. If you want to merge into the new branch dev-service-20210121-new, you also need to right-click the module and push it (Cherry pick to the local code part is submitted by default, no need to commit).
5. This is all done, and then you can merge from the new branch dev-service-20210121-new to the dev branch (without the content submitted by the A team). If there is a bug in the testing phase, the code to be changed should also be changed on dev-service-20210121-new.
So far, through the Git Cherry-Pick (cherry picking) method, the requirement for only some functions to be launched has been achieved.