Git Rebase实战踩坑指南 从新手误区到高级技巧的完整总结

Git的Rebase和Merge，我为什么更推荐Rebase

做前端这么久了，代码版本管理这块儿踩过不少坑。今天聊聊Git的rebase和merge这两个命令，说实话，我现在的项目基本都用rebase，虽然网上争议挺大，但用习惯了确实舒服。

先说说为啥要对比这两个。主要是因为团队里总有同事问到底该用哪个，特别是刚入行的同学，经常把提交历史搞得一团糟。我之前接手过一个项目，合并请求出来几十个”Merge branch”的提交记录，看得我眼花缭乱，后来改成统一用rebase后清爽多了。

从实际使用角度看：哪个更清爽？

先看看merge的基本用法：

git checkout main
git merge feature-branch

这样做的结果就是会产生一个merge commit，如果你的feature-branch有很多提交记录，最终的主分支就会变成一个网状结构，各种分叉线交错。有时候为了保持这种网状结构还特意用no-ff参数强制生成merge commit，但我个人觉得这种做法在多人协作时会让提交历史变得很难追溯。

再看看rebase的用法：

git checkout feature-branch
git rebase main
git checkout main
git merge feature-branch

这样操作后，feature-branch的所有提交都会重新应用到main分支的最新状态上，最后合并的时候是个fast-forward操作，提交历史看起来就是一条直线，特别清爽。我比较喜欢这种线性的提交历史，看代码review的时候能很清晰地看到每个改动的来龙去脉。

不过这里要提一下风险，rebase的本质是重写提交历史，如果你已经push了代码到远程仓库，然后又rebase了，这时候如果别人基于你原来的提交做了开发，那就会出问题。这就是为什么我一般只对本地还没push的分支使用rebase。

交互式rebase：真正的大杀器

其实rebase最有用的功能是交互式操作，这个用起来简直不要太爽：

git rebase -i HEAD~3

这条命令会打开编辑器，让你可以选择如何处理最近的3次提交。比如squash把多个提交合并成一个，或者edit修改某个提交的内容。我在做code review的时候经常用这个功能，把零散的调试代码、修复bug的提交都合并起来，最后只留下几个有意义的提交记录。

而merge就没有这种灵活性，它只能简单地把两个分支合并在一起，如果你想整理提交历史，得用别的工具或者手动修改，麻烦得很。

交互式rebase还有个好处是可以在提交前检查代码质量。我经常用它来重构提交信息，确保每条提交都有意义。有些团队要求提交信息必须遵循特定格式，用rebase -i就能很好地统一格式。

团队协作中的实际体验

说说在真实项目中的感受。我参与过的几个项目，用merge的话，一个月下来main分支的提交历史能有几百条，大部分都是merge commit。找bug的时候需要过滤掉这些merge记录才能看到真正的代码变更，效率很低。

换成rebase后，整个项目的提交历史清晰了很多。特别是配合GitHub的Squash and Merge功能，PR里的所有提交都能被整合成一个有意义的提交，maintainer不用关心你在开发过程中试错了多少次。

当然，rebase也不是完美无缺的。最大的问题是冲突处理比merge复杂，特别是当你rebase的分支历史很长时，可能需要多次解决冲突。而且对于新手来说，rebase的概念理解起来确实比merge要困难一些。

我踩过好几次坑就是当rebase遇到冲突后，不知道怎么退出或者恢复。现在我的习惯是每次rebase前都会创建一个备份分支，以防万一。

我的选型逻辑：什么情况用什么

说说我现在的选择标准。日常开发中，我会在feature分支上rebase主分支的最新代码，确保自己的代码基于最新的主分支开发。然后通过PR合并到主分支时，通常会用Squash and Merge，这样主分支保持干净的同时也不破坏别人的开发历史。

如果是在紧急修复的情况下，我会直接在hotfix分支上rebase到需要修复的分支，快速验证后直接fast-forward合并，这样可以避免额外的merge commit。

但是有两个场景我还是会用merge：

• 团队协作中，如果有同事不熟悉rebase，为了避免造成混乱，我会配合使用merge
• 某些重要的里程碑节点，我会特意保留分支信息，用merge保留分叉的历史轨迹

总的来说，rebase更适合追求整洁提交历史的项目，特别是开源项目。而merge则更适合对提交历史要求没那么严格的短期项目。

一些实用的小技巧

在实际使用中我还发现了一些有用的技巧。比如git pull的时候可以用–rebase参数，默认使用rebase而不是merge：

git config --global pull.rebase true

这样设置后，每次pull都会自动rebase，避免了不必要的merge commit。不过要注意，这个设置可能会让某些CI/CD工具不兼容，所以要根据实际情况决定。

还有一个技巧是用git rebase –onto，这个命令可以让你把某个分支的一部分历史应用到另一个分支上。比如你想把feature-a分支中的几个提交应用到feature-b分支，就可以用这个命令。虽然平时用得不多，但关键时刻特别有用。

最后要说的是，无论用哪种方式，最重要的是团队内部要统一。我之前遇到过团队里有人用merge有人用rebase，结果提交历史乱成一锅粥，最后只能制定规范统一使用某一种方式。

以上是我对Git rebase和merge的一些对比总结，有不同看法欢迎评论区交流。这个技巧的拓展用法还有很多，后续会继续分享这类博客。