Git合并分支后遇远程更新，推送受阻的方案选择疑问

嘿，这个场景我在日常协作里碰到过好多次！咱们先把问题理清楚，再聊聊两种方案的坑和更合适的选择：

你说的情况大概是这样的：

1. 你把远程的feature分支合并到本地master：

   git merge origin/feature
   

2. 费了半天劲解决完代码冲突，准备推送到远程master时，发现有人已经往远程master推了新提交——这下本地master和远程master出现了分歧，直接push会被Git拒绝。

咱们挨个说你提到的两个方案：

方案1：git rebase origin/master #

• 好处：能让你的提交历史保持线性，看起来更干净——它会把你本地合并feature后的提交，“搬”到远程master最新提交的后面，就好像你是在远程最新代码的基础上做的合并一样。
• 致命坑：确实会破坏合并历史！如果这个feature分支之前已经被其他团队成员拉取过、基于它开发过，你改写历史后，其他人再拉取代码时会遇到大量冲突，甚至本地仓库会混乱。所以这个方案只适合你自己单独使用的分支，或者团队明确约定允许改写公共分支历史的情况。
• 额外提醒：如果之前已经把本地合并后的提交推过一次远程，那rebase后需要用git push --force-with-lease来推送（比git push --force安全，不会覆盖别人刚推的代码）。

方案2：git merge origin/master #

• 好处：完全不会改写历史，所有提交（包括你的合并和别人的新提交）都会被完整保留下来，对多人协作的公共分支非常友好，不会坑到队友。
• 槽点：正如你说的，会产生一个无意义的合并提交——这个提交里几乎没有实际的代码变更，只是为了把远程新提交和你本地的合并结果“粘”到一起。如果团队里经常出现这种情况，提交历史会变得分叉满天飞，看起来乱糟糟的，后期排查问题时找提交记录会很麻烦。

根据不同场景选对应的方案：

• 如果你在个人开发的私有分支（比如自己的feature分支，或者团队里只有你碰master的小项目）：放心用rebase，历史干净清爽，命令流程是：

  # 拉取远程master最新代码
  git fetch origin master
  # 变基到远程master之上
  git rebase origin/master
  # 解决变基过程中出现的冲突，然后继续变基
  git rebase --continue
  # 推送（如果之前推过，用--force-with-lease）
  git push --force-with-lease
  

• 如果你在多人协作的公共master分支：老老实实选merge，虽然多了个合并提交，但能保证团队协作的稳定性，命令流程是：

  # 拉取远程master最新代码
  git fetch origin master
  # 合并远程master到本地
  git merge origin/master
  # 解决冲突（如果有的话），然后提交合并结果
  git commit
  # 推送
  git push
  

其实可以从源头减少这种情况：在合并feature到master之前，先把远程master的最新代码拉到本地master，也就是先执行：

git pull origin master

然后再合并feature，这样能提前解决冲突，等你推送到远程时，大概率不会遇到别人已经提交新代码的情况，省去后续的麻烦。

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