Git Rebase实战技巧与常见坑点解析

Rebase：我的写法，亲测靠谱

大家好，我是前端老司机一枚，今天想跟大家分享一下我在使用 Git Rebase 过程中的一些实战经验。Rebase 是个好东西，用好了能让你的 Git 历史记录变得清晰干净，但用不好也会让你头大。我一般这样处理：

基本用法：保持分支干净

Rebase 的核心功能是将一个分支的更改应用到另一个分支上。我最常用的是将 feature 分支的更改应用到 main 分支上。这样做可以让 Git 历史记录更加线性，便于追踪。

git checkout feature-branch
git rebase main

这样做的好处是，feature-branch 上的所有提交都会被重新应用到 main 分支的最新提交上。当然，前提是 main 分支已经更新了最新的代码。

这几种错误写法，别再踩坑了

首先，千万不要在公共分支（如 main 或 develop）上直接使用 Rebase。因为 Rebase 会重写历史记录，如果你在一个大家都依赖的分支上做了这个操作，其他人拉取时可能会出现冲突或者丢失提交。我曾经在项目中就遇到过这种情况，导致整个团队都要重新同步代码，非常麻烦。

git checkout main
git rebase feature-branch  // 千万不要这样做

其次，不要在同一个分支上反复使用 Rebase。比如你在 feature-branch 上做了一次 Rebase，然后又在 main 分支上做了一次 Rebase，这样会导致 Git 历史记录混乱，难以追踪。我的建议是尽量在合并前只做一次 Rebase。

交互式 Rebase：解决冲突和清理提交

有时候，我们需要对一些提交进行修改，比如合并多个提交、修改提交信息等。这时候，交互式 Rebase 就派上用场了。

git rebase -i HEAD~5

这条命令会打开一个编辑器，列出最近的 5 个提交。你可以在这个编辑器中选择不同的操作，比如 pick、squash、reword 等。举个例子，如果你想把两个提交合并成一个，可以在第二个提交前面加上 squash，然后保存退出。

交互式 Rebase 的好处是可以让你灵活地管理提交记录，但也有风险。比如，如果你不小心删除了一些重要的提交，恢复起来会很麻烦。所以，我一般会在 Rebase 前先备份当前分支：

git checkout -b backup-branch
git rebase -i HEAD~5

实际项目中的坑

在实际项目中，使用 Rebase 最常见的问题是冲突。当你的本地分支和远程分支有大量改动时，很容易出现冲突。我一般这样处理：

1. 首先，确保本地分支是最新的：

git fetch origin
git checkout feature-branch
git rebase origin/main

2. 如果出现冲突，Git 会提示你哪些文件有冲突。你需要手动解决这些冲突，然后继续 Rebase：

git add conflicted-file
git rebase --continue

3. 如果某个冲突解决不了，可以使用 git rebase --abort 回退到 Rebase 前的状态。

此外，还有一个小技巧：如果你只想 Rebase 某些特定的提交，可以使用 --onto 选项。比如，你想把 feature-branch 上的某几个提交应用到 hotfix-branch 上：

git rebase --onto hotfix-branch main feature-branch

这条命令的意思是，将 feature-branch 上的提交从 main 分支开始，应用到 hotfix-branch 上。

结尾：以上是我总结的最佳实践

以上就是我在使用 Rebase 过程中总结的一些实战经验。希望对你有所帮助。如果有更好的方案或者你有什么问题，欢迎在评论区交流。这个技巧的拓展用法还有很多，后续我会继续分享这类博客。