将分支并入main前，为什么要用rebase合入main而非直接merge main到分支？

首先纠正一个常见的表述误区：实际操作是在你的开发分支上执行git rebase main，也就是把你的开发分支的所有提交，嫁接在当前最新的main分支提交之后，不是把main rebase到你的本地分支。

两者的核心差异可以直观理解为：

• 执行git merge main到开发分支：会额外生成一个合并提交，把main的提交线和你的开发分支提交线拧到一起
• 执行git rebase main：会把你的开发分支的提交挪动到main最新提交的后面，整个提交线是一条干净的直线

选择rebase的核心优势 #

• 提交历史干净无冗余
  整个仓库的提交线是线性的，后续排查问题、回滚版本的时候不需要在杂乱的合并节点里找对应提交，git log的输出一目了然，不会出现大量无意义的「合并main到xxx分支」的提交记录。
• 合并冲突处理更合理
  rebase是逐个应用你的开发分支提交，遇到冲突时可以对应到每个具体的功能提交去解决，解决完的冲突会直接写到对应的提交里，不会留下独立的合并冲突提交。而merge main的冲突是一次性暴露所有差异，解决完的内容都存在合并提交里，后续很难追溯当时的冲突对应哪个功能修改。
• 后续PR/MR的审核更高效
  线性提交历史可以让审核者直接按顺序看你的功能提交，不需要区分哪些是你写的代码、哪些是从main合并过来的代码，审核效率高很多。
• 后续回退操作更简单
  如果你的功能分支合并到main后发现问题要回滚，直接回退你那一串连续的提交即可。如果是用merge的方式，提交线交织，回滚时很容易误操作把main上的其他提交也一起回退。

什么情况不建议用rebase #

如果你的开发分支是多人协作的公共分支，不要随便执行rebase，因为rebase会修改提交哈希值，会导致其他协作者的本地分支和远程分支不一致，后续同步会出现大量冲突。只有你自己独用的本地开发分支，才适合执行rebase操作。

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