GitLab squash合并feature/1到deploy后，衍生的feature/2合入冲突如何解决

你之前合并feature/1到deploy分支时勾选了squash commits选项，该操作会把feature/1上的所有提交压缩为1个全新的提交写入deploy分支，不会保留和原有feature/1分支提交的关联关系。而feature/2是从未改动的旧feature/1分支切出的，自带了feature/1的所有原始提交，这些提交在deploy分支上不存在对应的commit hash，因此创建MR时Git会把这些旧提交也算作待变更内容，和deploy上已经压缩的feature/1内容比对就会触发冲突。

你不需要操作第一次的MR，两个选项都不适用当前场景：

• revert：生成新提交回滚第一次MR合并到deploy的所有改动，相当于把deploy恢复到合并feature/1之前的状态，完全不符合需求，不要使用。
• cherry-pick：将第一次MR压缩后的提交单独复制到其他指定分支，当前场景不需要迁移该提交，因此也不需要使用。

方案一：变基feature/2分支（推荐，无冗余分支生成） #

1. 拉取本地最新的deploy分支代码：

git checkout deploy
git pull origin deploy

2. 切换到feature/2分支：

git checkout feature/2

3. 执行变基操作，将feature/2的独有提交迁移到最新deploy分支之上：

先执行git log --oneline找到feature/1分支最后一个提交的hash值，记为<feature1-last-commit-hash>

git rebase --onto deploy <feature1-last-commit-hash> feature/2

变基过程如果出现冲突，解决冲突后执行git add .，再运行git rebase --continue即可，直到变基完成。

4. 强制推送本地修改后的feature/2到远端：

git push origin feature/2 --force

5. 回到GitLab的MR页面，此时MR只会展示feature/2独有的变更，原有冲突也会消失。

方案二：新建分支迁移改动（适合对rebase操作不熟悉的场景） #

1. 基于最新deploy分支创建新的开发分支：

git checkout deploy
git pull origin deploy
git checkout -b feature/2-new

2. 把feature/2的独有提交cherry-pick到新分支：

先执行git log --oneline找到feature/2第一个独立提交到最新提交的hash范围，记为<start-commit>^..<end-commit>

git cherry-pick <start-commit>^..<end-commit>

3. 解决冲突后推送新分支到远端，基于feature/2-new创建新的MR即可。

内容的提问来源于stack exchange，提问作者Arzybek