在gitlab上操作cherry-pick(中文页面上是优选)报了下面的问题
Sorry, we cannot cherry-pick this commit automatically. This commit may already have been cherry-picked, or a more recent commit may have updated some of its content.
这个提交可能已经被挑选出来了，或者最近的提交可能已经更新了它的一些内容。刚看到的时候还不太理解什么叫最近的提交可能已经更新了它的一些内容。加上一些‘迷惑行为’，对于理解出现了偏离，所以就新建了分支测试一下。具体步骤如下：
-
我们现在有三个分支
- new（开发的新需求）
- old（历史版本，也可以当作master的稳定版本，要往这上面cherry-pick）
- three（新做的第三方需求）
-
迷惑行为是什么呢，把three分支merge到了old上，然后将three分支上的最新提交cherry-pick到了new分支上，这导致这个提交merge了两次，当我
git log --graph发现这次cherry-pick的提交插入了进来，误以为是这里的问题 -
然后在new分支上又提交了三次新的代码
- 第一次：新增了一个文件，然后写了点代码
- 第二次：改了点别的文件
- 第三次：在第一次新增的文件里删了一行代码
-
当想把第三次提交cherry-pick到old分支上时，就会报上面的问题
一开始理解的最近的提交可能已经更新了它的一些内容是因为上面的迷惑行为，我在这个分支上的提交（cherry-pick的three代码）已经被更新在我想cherry-pick的分支（old上merge了three的代码）上了，所以它不允许重复提交。(感觉有点绕)
然后就尝试复现上面的操作，在我分别在两个分支上合了three的代码后，cherry-pick第一次新增文件的提交时，并没有报上述错误，所以发现是理解有误。
然后开始继续后面的三次提交，当cherry-pick第三次提交的时候，报了上述错误
直接打开vscode去命令行看看啥问题，当cherry-pick第三次提交的时候，会发现报了冲突，说新增的文件被你改动了，但是被old删除了，实际上old分支从来没有出现过这个文件，只是因为你这个文件的新增记录是在第一次提交上，但当你想略过第一次提交直接cherry-pick第三次的时候就会报这个问题。
结尾：
- 每一次提交的时候还是要注意独立性，避免某个公共文件在某次提交新增上来，后续改动的时候你以为公共文件没有影响。。。实际上。。。
- 合代码的时候一定要先拉取代码解决冲突，如果要做代码隔离，可以新拉第三个分支来做这个操作
- cherry-pick要按照时间线去提交
