git: 恐怖的无限cherry-pick

cherry-pick

cherry-pick的应用场景一般是把分支B上的某次commit合并到分支A上。假设分支A和分支B具有共享代码或者文件，当在分支B上对共享的代码或者文件进行了一次新的提交之后，此时如果要从B分支合并该次新的commit到A分支，需要使用到git cherry-pick。

恐怖的cherry-pick

就在今天，我一头扎进了必须要使用cherry-pick的坑里。

公司的某项目是多个团队共同开发的项目，也就是若干个项目都需要依赖的一个后台项目，具有测试服和正式服，分别是develop和master分支。一个月以来，我一直在develop分支上commit/pull/push，轻轻松松。

直到今天，我们组的某项目要上线，依赖于该后台项目。我发现我要把曾经做过的修改全部提交到master分支上，啊 太上头了。。

起初我是这么合并的

我想，虽然一个多月了，但是我的修改只有三个文件，也就是说，除了这三个文件，其他文件我都没有做修改，ok，那我直接把这三个文件从develop提交到master上面不就行了？于是乎：

# 当前在master分支
# * master

# 把develop做过修改的三个文件提交到master分支
git checkout develop utils.py
git checkout develop constants.py
git checkout develop my_views.py

# add/commit
git add .
git commit -m "feat: 提交我近一个月的修改"

我认为大功告成！原来这么简单？
不，事情没有这么简单！

后来我发现…我开始慌了

细心的同学也许会发现：utils.py constants.py my_views.py难道不会被其他项目组的人修改吗？

这确实是我马虎的一点，在这一个月以来，多少人在develop上多次提交修改，utis.py constants.py（my_views.py是我们的文件，其他组不会修改的）早就被修改了好多次了。所以到今天，我提交的这两个文件，不仅有自己的修改，也存在其他人的修改，所以我依然坚持提交这三个文件的话，会造成一个问题：

1. 我把别人的修改作为自己的修改提交了，别人日后再提交的时候，会出现重复的代码，项目会报错，不容易查错。

已经push到远程仓库，没有强制回退版本的权限

然后我在想，能不能回退版本，回到我没有push的那个commit，然后基于那个commit逐个从develop添加我之前做的commit到master，但是，没有强制回退commit的权限，于是乎就不考虑回退commit的方式了。

现在只有从当前远程的最新的commit开始往下进行。

首先，我要恢复那三个文件。在我push之前的那个commit_id是：0112d****，我要从这个commit拉取被我覆盖掉的utils.py constants.py my_views.py，执行如下命令：

# 当前分支
# master
git checkout 0112d utils.py
git checkout 0112d constants.py
git checkout 0112d my_views.py

git add .
git commit -m "恢复被我覆盖掉的三个文件修改"

开始搬运commit

从master创建一个新的分支：bsj_master

打开vscode，随时准备操作代码解决发生的冲突！

新建两个窗口同时进行，一个窗口切换到develop分支查找所有自己的commit_id。另一个窗口切换到bsj_master分支，通过git cherry-pick <commit_id>从最早的commit开始进行合并操作。（中间也许会遇到冲突，需要手动解决）

# 当前所在分支 bsj_master
# 1. 合并commit
git cherry-pick 9de93
# 2. 检查当前合并后的内容与bsj_master的差别，确保合并的是自己想要的修改
git diff bsj_master
# 3. 如果有冲突，使用vscode手动解决
# 4. 解决完冲突，重复执行 git diff bsj_master 检查代码
# 5. add/commit当前合并

重复以上步骤直到所有的分支合并完成，就大功告成了～

总的来说，就是要先理清自己的思路，要想明白怎么样能够让分支回到正轨，不会影响到后面别人的提交以及正常工作，然后一定要按照清晰的思路来进行合并。

大概的步骤就是最后一个代码段里描述的那样：

1. 从master分支最新的提交创建一个新的分支bsj_master
2. 在新分支bsj_master上恢复之前的文件修改，并提交
3. 从develop合并修改到bsj_master上：
   a. git cherry-pick <commit_id>
   b. git diff bsj_master
   c. 有冲突则手动解决冲突
   d. git diff bsj_master检查代码
   e. add/commit 当前合并

---

哈哈哈，小伙伴们，以后记得不要在多个人都会修改的分支上工作啊，要从工作分支新建自己的分支，然后做完修改再提交到工作分支上～