如何在GitHub中将两人的分支修改合并至master分支？

听起来你遇到的是团队协作里很常见的分支历史脱节导致的合并覆盖问题——别担心，咱们一步步梳理清楚，搞定它。

为什么会出现全量覆盖？ #

这种情况几乎肯定是因为你同事的branch C是基于合并B之前的旧master创建的。当你把B合并到master后，新master的提交历史和C分支完全脱节了，这时候直接向新master提交C的PR，Git会判定这是两个完全独立的分支，合并时就容易出现全量覆盖的情况（尤其是当分支差异过大，GitHub默认的合并策略没法自动处理时）。

解决方案（分两种场景） #

场景1：还没把branch C合并到master（推荐路径） #

让你的同事在本地把最新的master（已经包含B的修改）合并到C分支，解决冲突后再提交PR，就能实现你想要的「保留已有修改、新增C的内容」的效果：

1. 切换到本地的branch C：

git checkout branch C

2. 拉取远程最新的master分支：

git fetch origin master

3. 将最新master合并到branch C，Git会自动合并无冲突的内容，有冲突的话手动修改文件里标记的冲突部分即可：

git merge origin/master

4. 解决完冲突后，提交合并结果：

git add .
git commit -m "Merge latest master into branch C"

5. 把更新后的branch C推送到远程：

git push origin branch C

这时候再发起PR到master，GitHub就会显示C相对于最新master的增量修改，合并后只会加入C的新内容，不会覆盖之前B的修改。

场景2：已经合并了branch C导致覆盖 #

如果已经不小心合并了C导致master被覆盖，咱们先回退master到合并C之前的状态，再按上面的步骤重新处理：

1. 查看master的提交历史，找到合并B之后、合并C之前的那个提交哈希（可以用git log --oneline快速查看，比如输出里类似abc123 Merge branch B into master的那一行）：

git log --oneline

2. 切换到master并回退到那个提交：

git checkout master
git reset --hard abc123

3. 强制推送到远程master（⚠️ 注意：这个操作会修改远程master的历史，一定要提前和团队成员沟通，避免其他人拉取错误版本）：

git push origin master --force

4. 之后让同事按场景1的步骤更新branch C，重新发起PR即可。

预防措施（避免下次再踩坑） #

• 团队成员定期将最新的master合并到自己的开发分支，保持分支历史同步。
• 在GitHub仓库的设置里开启「Require branches to be up to date before merging」，这样GitHub会强制要求PR分支必须先和最新master合并才能提交，从源头避免覆盖问题。
• 如果喜欢线性提交历史，可以用git rebase origin/master代替git merge，把自己的提交「移到」最新master的上面，但rebase会修改提交历史，适合个人开发分支，团队协作时要提前确认规则。

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