Git基础：将旧分支合并至master的疑问与最佳实践

1. git merge new-changes 会做什么？ #

绝对不会把master回退到「new-changes」创建时的状态！Git的merge操作本质是将目标分支（这里是new-changes）自共同祖先以来的所有变更，合并到当前分支（你正在操作的master）的最新状态。

具体来说，Git会先找到master和new-changes的最近共同提交点（也就是你当初创建new-changes分支时的那个master版本），然后把new-changes从这个点之后新增的所有提交，应用到当前master的最新代码上。如果过程中没有代码冲突，Git会自动生成一个合并提交；如果有冲突，它会暂停合并，提示你手动解决冲突后再完成提交。

简单说：merge是把new-changes的新变更追加到master的最新版本上，而不是回退。

2. 合并「new-changes」到master的最佳方式 #

选择哪种方式取决于你的团队协作习惯和对提交历史的要求，下面是几种常用方案：

方案一：常规合并（保留完整分支历史） #

适合需要保留new-changes分支所有提交记录的场景，步骤如下：

• 先确保本地master是最新的：

  git checkout master
  git fetch origin
  git pull origin master
  

• 执行合并：

  git merge new-changes
  

• 如果出现冲突，打开冲突文件解决标记（<<<<<<<、=======、>>>>>>>），然后：

  git add <解决冲突的文件>
  git commit
  

• 最后推送到远程：

  git push origin master
  

这种方式的优点是历史完整，能清晰看到分支的演进过程；缺点是如果new-changes有很多小提交，master的历史会显得比较零散。

方案二：变基后合并（得到线性提交历史） #

如果希望master的提交历史更整洁、线性，可以先把new-changes变基到最新的master上，再合并：

• 切换到new-changes分支：

  git checkout new-changes
  

• 执行变基，把new-changes的提交“移到”最新master的后面：

  git rebase master
  

• 过程中如果遇到冲突，解决后执行：

  git add <解决冲突的文件>
  git rebase --continue
  

  （如果想跳过当前提交用git rebase --skip，放弃变基用git rebase --abort）
• 变基完成后，切换回master执行快进合并：

  git checkout master
  git merge new-changes
  

• 推送到远程：

  git push origin master
  

⚠️ 注意：如果new-changes分支已经被其他团队成员拉取过，不要使用变基！变基会修改分支的提交历史，导致其他人的本地仓库出现冲突。

方案三： squash合并（合并为单一提交） #

如果new-changes上的多个小提交都是为了完成同一个功能，想把它们合并成一个干净的提交记录，适合用squash合并：

• 确保本地master是最新的（同方案一的第一步）
• 执行squash合并：

  git merge --squash new-changes
  

• 这时候Git会把new-changes的所有变更都暂存起来，但不会自动生成提交，你需要手动提交并写一个清晰的提交信息：

  git commit -m "feat: 完成XX功能（合并new-changes分支的所有变更）"
  

• 推送到远程：

  git push origin master
  

这种方式的优点是master的历史非常整洁，每个功能对应一个提交；缺点是会丢失new-changes分支上的单个小提交记录。

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