Git squash-merge策略下派生特性分支的冲突解决与同步方案

冲突的核心原因是squash-merge的机制特性：特性分支被压缩合入主干时，Git会生成一个全新的独立提交，这个提交和原特性分支上的零散开发提交没有祖先关联关系，Git无法自动识别主干已经包含了原work1分支的全部代码改动。
此时直接执行git rebase master work2，Git会把work2提交历史里继承自work1的所有旧提交也尝试重新应用到主干上，本质是把相同的代码改动重复写入一遍，自然会触发大量无意义的伪冲突；直接用cherry-pick如果没有精准筛选提交，也会把work1的旧提交带到新的提交历史里，造成日志冗余杂乱。

使用带--onto参数的定向变基命令，精准跳过已经被squash合入的父分支提交，只保留派生分支work2上的自有改动，全程不会产生冗余提交，也只会在代码真的存在逻辑冲突时才需要手动处理，完全符合squash-merge团队的提交规范。
对应你的场景操作步骤如下：

• 确保本地master分支是最新的、已经包含work1被squash合入的代码
• 执行定向变基命令：

git rebase --onto master work1 work2

命令参数说明：

• --onto master：指定变基的目标基底是最新的主干分支
• 第二个位置的work1：指定变基时需要丢弃的提交范围——也就是所有属于原work1分支的旧提交，这些代码已经通过squash合入主干，不需要重复应用
• 第三个位置的work2：指定本次操作的目标分支是work2
• 如果执行过程中提示冲突，先手动解决文件里的冲突内容，执行git add <冲突文件路径>标记冲突已解决，再执行git rebase --continue完成剩余流程即可；如果没有真实逻辑冲突，命令会直接执行完成。

在你提供的复现场景中执行上述命令，不会再出现尝试应用work1旧提交067ee68的报错，变基完成后：

• work2分支直接基于最新的master，提交历史仅包含master的初始提交、work1的squash合入提交、work2上的两个自有开发提交，无任何冗余记录
• test.txt文件内容完全符合预期：

test!
1. Added this!
2. Added more
3. Added even more
4. last commit that will finally fix the CI

后续直接给work2提PR走正常squash-merge流程即可，不会再触发无意义冲突。

• 如果原work1分支已经被删除，不需要特意找回分支，只需要找到当初拉取work2时work1的最后一个提交哈希值，替换命令里的work1参数即可，效果完全一致
• 禁止对这类依赖未合入特性的派生分支直接执行普通git rebase master操作，会触发大量重复应用提交导致的伪冲突
• 用cherry-pick处理这类场景时，必须精准筛选出派生分支独有的提交范围，不要把父分支的旧提交拣入目标分支，否则会污染提交历史

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