About the git cherry-pick command and understanding during use: The git cherry-pick [commit id] command is designed to synchronize content on different branches of the same warehouse, for example,
the same project (must be the same warehouse) is in the development process Many branches have been created. If the a branch is very stable and is a release version, the b branch is specially used to test new functions. Now I want to synchronize a more eye-catching function of the b branch to the a branch. Due to the development process Moving forward, it is definitely not possible to merge the b branch into the a branch now, otherwise there will be various conflicts and bugs or even crashes. If this happens, then this command is very suitable for this scenario; when using this command to synchronize each commit id There will definitely be hint conflict prompts. If there is a conflict, use the git status ./ command to see which files are in conflict. It is nothing more than add by us / both modified / delete by us /delete by them and so on!
The premise of understanding these conflicts is to first understand who is us and who is them. According to the previous example, it is necessary to synchronize the b branch to the a branch. People must be working on the a branch, then us is the a branch, and them is the b branch. Then the delete by us conflict is found in the process of synchronizing a commit id, there is a file on the b branch that is not on the a branch, so the conflict prompt is deleted by this branch, and after the commit, it will be in this branch (a branch) Create the file above, and let’s talk about add by us. I haven’t tested it specifically. Personally, I feel that the git commit -a command is executed in a directory of the b branch, so when the git cherry-pick command is executed, the a branch will be executed. This directory is all synchronized, and it turns out that there is a certain file or folder on branch a that is not on branch b, so the prompt add by us, in fact, these conflicts can be ignored, you can directly use git commit -a to submit, the consequences It's nothing more than adding or deleting the file, it doesn't matter, but there is a conflict prompt that must be resolved manually, that is, both modified, because once the git cherry-pick command is executed, the both modified conflict prompt appears, then the file must have <<<<<<< and ======= and >>>>>>>, and also with the commit log information of the commit id, these things will definitely cause the program to fail to compile, so the conflict must be resolved manually, if it is not a program file , the appearance of these things will not cause any consequences. In fact, you can ignore it. It is also possible to directly git commit -a. In addition, you need to know that the content between <<<<<<< and ======= is this The content modified on the branch (a branch), the content between ======= and >>>>>>> is the content modified by the b branch (them); there is also the execution of git cherry-pick [commit id] The previous cherry-pick is now empty,The prompt possibly due to conflict resolution, then the modification content of the commit id on the a branch and the b branch is already consistent, and there is no need to synchronize;
the same project (must be the same warehouse) is in the development process Many branches have been created. If the a branch is very stable and is a release version, the b branch is specially used to test new functions. Now I want to synchronize a more eye-catching function of the b branch to the a branch. Due to the development process Moving forward, it is definitely not possible to merge the b branch into the a branch now, otherwise there will be various conflicts and bugs or even crashes. If this happens, then this command is very suitable for this scenario; when using this command to synchronize each commit id There will definitely be hint conflict prompts. If there is a conflict, use the git status ./ command to see which files are in conflict. It is nothing more than add by us / both modified / delete by us /delete by them and so on!
The premise of understanding these conflicts is to first understand who is us and who is them. According to the previous example, it is necessary to synchronize the b branch to the a branch. People must be working on the a branch, then us is the a branch, and them is the b branch. Then the delete by us conflict is found in the process of synchronizing a commit id, there is a file on the b branch that is not on the a branch, so the conflict prompt is deleted by this branch, and after the commit, it will be in this branch (a branch) Create the file above, and let’s talk about add by us. I haven’t tested it specifically. Personally, I feel that the git commit -a command is executed in a directory of the b branch, so when the git cherry-pick command is executed, the a branch will be executed. This directory is all synchronized, and it turns out that there is a certain file or folder on branch a that is not on branch b, so the prompt add by us, in fact, these conflicts can be ignored, you can directly use git commit -a to submit, the consequences It's nothing more than adding or deleting the file, it doesn't matter, but there is a conflict prompt that must be resolved manually, that is, both modified, because once the git cherry-pick command is executed, the both modified conflict prompt appears, then the file must have <<<<<<< and ======= and >>>>>>>, and also with the commit log information of the commit id, these things will definitely cause the program to fail to compile, so the conflict must be resolved manually, if it is not a program file , the appearance of these things will not cause any consequences. In fact, you can ignore it. It is also possible to directly git commit -a. In addition, you need to know that the content between <<<<<<< and ======= is this The content modified on the branch (a branch), the content between ======= and >>>>>>> is the content modified by the b branch (them); there is also the execution of git cherry-pick [commit id] The previous cherry-pick is now empty,The prompt possibly due to conflict resolution, then the modification content of the commit id on the a branch and the b branch is already consistent, and there is no need to synchronize;