多开发者协作中，功能分支合并的正确方法及未察觉变更规避

你遇到的核心问题是直接合并整个feature分支会混淆代码归属，导致后续修改共享文件时Git无法识别冲突——因为开发者2的修改是基于feature1的提交，Git会认为这是对feature1代码的延续，而非和master基线的冲突，最终导致feature1开发者不知情。

下面是几种可行的解决方案，从代码操作到团队规范层面逐一解决：

1. 用git cherry-pick只引入需要的代码 #

不要合并整个branch_feature1，而是只挑选feature2真正需要的特定提交。比如你的示例中，开发者2只需要用到提交1（修改feature1_constants.h的部分），完全不需要提交2的内容。

操作步骤：

# 切换到你的feature2分支
git checkout branch_feature2
# 挑选branch_feature1中需要的那个提交（替换成实际的提交哈希）
git cherry-pick <commit1的哈希值>

这样只会把需要的代码引入feature2，后续如果修改common_constants.h，你的修改基线是master的原始值（10），而非feature1的修改值（100），合并回master时就会触发冲突，提醒你和feature1开发者同步修改。

如果cherry-pick时遇到冲突，直接解决即可——这反而能提前暴露代码依赖问题，比后续隐性覆盖更安全。

2. 把共享代码抽成独立组件 #

如果多个feature分支需要共享部分代码（比如common_constants.h），最好把这部分代码单独剥离成一个独立的子模块、类库或者单独的分支。

这样所有依赖该代码的分支都通过引用方式使用，任何对共享代码的修改都需要单独提交到共享组件，各个feature分支更新时会明确看到共享代码的变更，从根源上避免跨分支直接修改对方代码的情况。

3. 已合并分支的补救：交互式rebase清理历史 #

如果已经不小心把整个branch_feature1合并到了branch_feature2，可以用交互式rebase把不需要的提交从feature2的历史中移除：

git checkout branch_feature2
# 找到合并branch_feature1之前的那个提交哈希，执行rebase
git rebase -i <合并前的提交哈希>

在弹出的编辑器里，把不需要的提交（比如示例中的提交2）前面的pick改成drop，保存退出后，feature2的历史就只保留了你需要的feature1代码，后续修改共享文件时会和master基线对齐。

4. 团队协作层面的约束 #

• 明确分支边界：约定每个feature分支只负责自身功能的代码，禁止修改其他feature分支的专属代码；如果要修改共享代码，必须先提交到master或专门的共享分支，再同步到各个feature分支。
• 合并前代码评审：任何分支合并到master前必须经过代码评审，检查是否存在跨分支修改的情况，确保共享代码的变更通知到相关开发者。

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