如何用其他branch替换master分支代码？是否应使用rebase？

是否应该使用rebase？ #

• 如果你的分支是私有分支（仅你个人开发维护），rebase是可选方案——它能让提交历史更线性，避免生成冗余的合并提交。但如果该分支已经被其他开发者拉取过，绝对不要用rebase，因为这会重写提交历史，导致团队成员的本地仓库出现版本冲突，后续同步会非常麻烦。
• 即便分支是私有的，若它和master差异极大，rebase过程中可能会触发一连串的冲突，逐个解决反而比直接合并更耗时。这种场景下，直接用git merge --no-ff合并更稳妥：冲突是一次性集中处理，还能完整保留分支的开发轨迹，方便后续排查问题。

用其他分支替换master分支内容的正确方法 #

如果确定要让master完全继承目标分支的内容，有两种安全可行的方法：

方法1：强制重置master到目标分支（推荐，需团队共识） #

1. 切换到master分支：

   git checkout master
   

2. 重置master到目标分支的最新提交：

   git reset --hard <目标分支名>
   

3. 强制推送到远程仓库（必须提前告知团队所有人，避免覆盖他人未同步的提交）：

   git push --force-with-lease origin master
   

   用--force-with-lease比单纯--force更安全，它会检查远程master是否有你本地未同步的更新，防止误操作覆盖他人工作。

方法2：反向合并（保留历史记录） #

如果不想重写master的历史，可以用反向合并的方式：

1. 切换到目标分支：

   git checkout <目标分支名>
   

2. 合并master分支，使用-s ours策略，让目标分支内容完全覆盖master：

   git merge -s ours master
   

3. 切换回master，合并目标分支：

   git checkout master
   git merge <目标分支名>
   

4. 推送到远程：

   git push origin master
   

   这种方法会保留所有提交历史，但master最终的代码内容和目标分支完全一致。

关键注意事项 #

• 无论选哪种方法，必须和团队成员提前沟通确认，确保没人在master上有未提交或未同步的工作。
• 操作前建议备份master分支，以防失误：

  git checkout master
  git branch master-backup-YYYYMMDD
  git push origin master-backup-YYYYMMDD
  

  后续若出现问题，可从备份分支快速恢复。

内容的提问来源于stack exchange，提问作者Noam TheLoreFnatic Hadad