git: 恐怖的无限cherry-pick

小灰灰 2022-11-16 15:15 86阅读 0赞

## 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 当前合并

--------------------

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