1. 为什么你需要合并提交？
如果你用过 Git，大概率遇到过这种情况：为了修复一个 Bug，你连续提交了七八次，每次的提交信息都是“修复了一个小问题”、“再改一下”、“好像还有问题”、“这次应该对了”。一周后，你看着这条像贪吃蛇一样又长又乱的提交历史，自己都想不起来当时到底改了啥。或者，在向开源项目提交 Pull Request 之前，你希望将一系列实验性的、琐碎的中间提交，整理成几个逻辑清晰、意义明确的提交块，让维护者一眼就能看懂你的工作。
这就是git rebase合并提交（也称为“压缩提交”）大显身手的时候。它不是什么高深莫测的黑魔法，而是一个强大的历史编辑工具。简单说，它能让你把多个连续的提交，合并成一个或几个更整洁的提交。这不仅仅是让提交记录“好看”，它直接提升了代码历史的可读性、可维护性，也是在团队协作中体现专业性的一个细节。想象一下，你是在撰写一份清晰的修改文档，而不是留下一堆草稿纸。
很多人对rebase望而却步，觉得它会“重写历史”，很危险。确实，如果对已推送到公共分支的提交进行rebase，可能会给协作者带来麻烦。但对于尚未推送的本地提交，或者你个人特性分支上的提交，使用rebase来整理历史，是一种非常推荐的最佳实践。今天，我们就抛开恐惧，手把手、一步步地，把多个提交合并这件事，弄得明明白白。
2. 理解 Rebase 的“互动模式”：-i 参数是关键
git rebase命令本身用于重新应用提交，而合并提交这个特定功能，主要通过其交互模式来实现，也就是加上-i参数。
核心命令格式：
git rebase -i [commit-ish]这里的[commit-ish]可以是一个提交哈希、分支名，或者像HEAD~3这样的相对引用。这个参数指定了rebase 操作的起点。更准确地说，Git 会列出从[commit-ish]之后（不包含该提交）一直到当前HEAD的所有提交，供你编辑。
一个必须理解的概念：HEAD~n这是指定提交范围最常用的方式。HEAD指向你当前所在的提交。HEAD~1表示当前提交的父提交，HEAD~2表示祖父提交，以此类推。所以，git rebase -i HEAD~4意味着：“我要重新审视并编辑最近的 4 个提交”。
当你执行这个命令后，Git 会打开你配置的默认文本编辑器（如 Vim、VSCode、Nano），展示一个类似这样的列表：
pick a1b2c3d 第一次提交：添加用户登录功能 pick e4f5g6h 第二次提交：修复登录按钮样式 pick i7j8k9l 第三次提交：补充登录失败提示 pick m1n2o3p 第四次提交：优化登录接口性能 # Rebase x0y1z2a..m1n2o3p onto x0y1z2a (4 commands) # # Commands: # p, pick <commit> = use commit # r, reword <commit> = use commit, but edit the commit message # e, edit <commit> = use commit, but stop for amending # s, squash <commit> = use commit, but meld into previous commit # f, fixup <commit> = like "squash", but discard this commit's log message # x, exec <command> = run command (the rest of the line) using shell # b, break = stop here (continue rebase later with 'git rebase --continue') # d, drop <commit> = remove commit # l, label <label> = label current HEAD with a name # t, reset <label> = reset HEAD to a label # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line, THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted.这个界面就是你的“操作台”。最上面是按时间顺序列出的提交（最新的在最下面，这是个历史习惯）。每一行以命令开头（默认是pick），然后是提交哈希和提交信息。
注意：这个编辑界面里的提交顺序，是从旧到新排列的。最上面一行是最早的提交，最下面一行是最新的提交。这一点在规划合并操作时至关重要，因为
squash和fixup是向上合并的。
3. 实战演练：一步步合并你的提交
现在我们进入实战环节。假设我们有一个简单的项目，为了开发一个“计算器”功能，我们提交了以下历史：
add: 创建 calculator.py 框架feat: 实现加法函数 add()fix: 修正 add 函数参数校验feat: 实现减法函数 sub()docs: 为 calculator.py 添加注释
我们的目标是将这5个提交，合并成2个逻辑清晰的提交：一个包含加法的所有工作（提交1，2，3），一个包含减法和文档工作（提交4，5）。
3.1 第一步：启动交互式 Rebase
我们想合并最近5个提交，所以从第5个提交的父提交开始操作，即HEAD~5。
git rebase -i HEAD~5执行后，编辑器会打开，显示如下内容：
pick abc1234 add: 创建 calculator.py 框架 pick def5678 feat: 实现加法函数 add() pick ghi9012 fix: 修正 add 函数参数校验 pick jkl3456 feat: 实现减法函数 sub() pick mno7890 docs: 为 calculator.py 添加注释3.2 第二步：规划并编辑命令
现在，我们需要修改每行开头的命令词，来告诉 Git 我们想怎么做。
pick：保留该提交，不做改动。squash(或缩写s)：将该提交合并到前一个提交中，并且会进入下一步，让你编辑合并后的新提交信息。fixup(或缩写f)：将该提交合并到前一个提交中，但丢弃当前提交的提交信息。当你有一些“修正打字错误”、“微调格式”的提交时，用这个最合适，可以自动融入前一个提交，不产生多余的提交信息编辑步骤。
根据我们的目标：
- 提交1（框架）作为加法功能的起点，我们保留它。
- 提交2和提交3是加法功能的实现和修正，应该被“压缩”进提交1。
- 提交4（减法）作为减法功能的起点，我们保留它。
- 提交5（文档）是针对整个文件的，我们可以把它“压缩”进提交4。
修改命令列表如下：
pick abc1234 add: 创建 calculator.py 框架 squash def5678 feat: 实现加法函数 add() squash ghi9012 fix: 修正 add 函数参数校验 pick jkl3456 feat: 实现减法函数 sub() squash mno7890 docs: 为 calculator.py 添加注释这里有一个非常重要的操作细节：squash和fixup是“向上合并”。也就是说，标记为s或f的提交，会被合并到它上面一行的提交中。你不能把第一个提交标记为squash，因为它上面没有提交可以合并。理解了这一点，你就能正确规划顺序。
3.3 第三步：编写新的提交信息
保存并关闭第一步的编辑界面后，Git 开始执行 Rebase 操作。当它遇到squash命令时，会再次打开编辑器，让你为合并后的新提交编写提交信息。
对于我们的例子，Git 会先处理前三个提交的合并。编辑器里可能会显示类似这样的内容：
# This is a combination of 3 commits. # This is the 1st commit message: add: 创建 calculator.py 框架 # This is the 2nd commit message: feat: 实现加法函数 add() # This is the 3rd commit message: fix: 修正 add 函数参数校验 # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit.你可以看到，它列出了所有将被合并的提交的原始信息。现在，你需要删除所有行（或者保留以#开头的注释行），然后编写一个新的、概括性的提交信息。一个好的提交信息应该简明扼要地说明这个提交块做了什么。
例如，我们可以写：
feat: 实现加法计算功能 - 创建 calculator.py 基础模块框架 - 实现 add(a, b) 函数，支持两数相加 - 为 add 函数添加基本的参数类型校验保存并关闭这个编辑器。接着，Git 会继续处理后面两个提交（减法与文档）的合并，并再次弹出编辑器让你编写第二个新提交的信息，比如：
feat: 实现减法功能并补充文档 - 实现 sub(a, b) 函数，支持两数相减 - 为 calculator.py 模块添加完整的函数注释3.4 第四步：完成与验证
所有编辑步骤完成后，Git 会完成整个 Rebase 过程。你可以使用git log --oneline --graph来查看新的提交历史：
* 5f6g7h8 (HEAD -> feature/calculator) feat: 实现减法功能并补充文档 * a1b2c3d feat: 实现加法计算功能 * x0y1z2a ... (之前的提交历史)看，原来杂乱无章的5个提交，现在变成了两个清晰、独立的特性提交。整个代码变更内容一点没少，但历史记录清爽多了。
4. 核心命令详解：pick, squash, fixup 的选择艺术
在交互式 Rebase 的编辑界面里，选择正确的命令是成功的关键。我们来深入理解一下这几个最常用的命令。
pick这是默认命令。简单来说，就是“保留这个提交，原封不动”。当你希望某个提交独立存在时，就用pick。通常，你会pick那些代表一个完整逻辑步骤、值得单独保留的提交。
squash与fixup：如何选择？这两个命令都能合并提交，核心区别在于如何处理被合并提交的日志信息。
squash：合并提交，并且保留被合并提交的提交信息，在下一步中，这些信息会一起呈现给你，供你编辑整合成一个新的信息。适用于：多个提交共同完成一个功能，且每个提交的信息都有参考价值，你想在最终信息中体现它们。例如，feat: A、feat: B、test: add for A&B可以合并成一个大的特性提交。fixup：合并提交，但完全丢弃被合并提交的提交信息。适用于：那些“修正前一个提交中的小错误”的提交，比如fix typo、adjust format。你肯定不希望最终的提交历史里留下一堆“修复错别字”的记录，用fixup可以让它们无声无息地融入前一个提交。
一个实用技巧：fixup的自动化如果你已经提交了代码，突然发现有个小地方要改（比如一个拼写错误），传统的流程是：修改 ->git commit --fixup <TARGET_COMMIT_HASH>。这个命令会创建一个提交，其信息自动标记为fixup! <原提交信息>。 之后，当你执行git rebase -i --autosquash HEAD~n时，Git 会自动为你将这些fixup!提交排序并设置为fixup命令，极大地简化了操作。这是保持历史整洁的利器。
reword这个命令非常有用。它允许你修改某个提交的提交信息，而不改变其内容。比如，你pick了一个提交，但后来觉得它的信息写得不清楚，就可以把pick改成reword。在 Rebase 过程中，Git 会在应用到那个提交时暂停，让你重新编辑提交信息。
edit这个命令更强大。它会在应用这个提交时暂停，允许你修改提交的内容（比如增删文件），修改完后用git commit --amend提交修改，然后用git rebase --continue继续。通常用于拆分提交或修改旧提交中的代码。
5. 必须掌握的注意事项与避坑指南
git rebase功能强大，但使用不当也会带来麻烦。下面这些坑，我几乎都踩过，希望你能避开。
5.1 黄金法则：只 Rebase 未推送的本地提交
这是最重要的一条规则。绝对不要对已经推送到远程仓库（如 GitHub、GitLab）的提交进行 Rebase，如果其他人可能已经基于这些提交进行了工作。
为什么？因为 Rebase 的本质是“丢弃旧的提交，创建一系列内容相同但哈希值全新的提交”。对于本地分支，这没问题。但对于远程分支，如果你强制推送 (git push --force) 这些新提交，就会覆盖远程历史。其他协作者如果已经拉取了你旧的提交，他们的本地历史会与远程历史产生分歧，在下次拉取或推送时遇到非常棘手的冲突，通常需要他们手动重置自己的分支，这会给团队协作带来灾难。
安全的工作流：
- 在个人特性分支上尽情使用
rebase来整理提交。 - 在准备合并（如发起 Pull Request）前，确保你的分支是基于目标分支（如
main）的最新代码rebase过的。 - 如果在此期间目标分支有更新，使用
git pull --rebase（而不是git pull）来合并更新，这样可以保持你的提交历史是线性的，避免不必要的合并提交。 - 只有在你确认你的分支历史是整洁的、线性的，并且只有你一个人在这个分支上工作时，才考虑使用
git push --force-with-lease（比--force更安全）来更新远程分支。在团队协作中，对共享分支应尽量避免强制推送。
5.2 处理 Rebase 过程中的冲突
在 Rebase 过程中，当 Git 尝试应用某个提交时，如果该提交的修改与当前代码状态冲突，它会暂停下来，让你解决冲突。
这时你会看到类似这样的提示：
Auto-merging calculator.py CONFLICT (content): Merge conflict in calculator.py error: could not apply abc1234... add: 创建 calculator.py 框架 Resolve all conflicts manually, mark them as resolved with "git add/rm <conflicted_files>", then run "git rebase --continue". You can instead skip this patch with "git rebase --skip". To abort and go back to the original state, run "git rebase --abort".解决步骤：
- 不要慌。使用
git status查看哪些文件有冲突。 - 打开冲突文件，你会看到
<<<<<<<，=======，>>>>>>>这样的标记。手动编辑文件，解决冲突，保留你想要的代码，删除这些标记。 - 解决完所有冲突后，用
git add <file>或git add .将文件标记为已解决。 - 运行
git rebase --continue让 Rebase 继续。 - 如果这个冲突的提交你不想处理了（比如它已经无关紧要），可以用
git rebase --skip跳过这个提交。慎用，因为这等于丢弃了这个提交的所有更改。 - 如果冲突太复杂，你想放弃整个 Rebase 操作，回到开始之前的状态，运行
git rebase --abort。这是你的安全绳。
5.3 后悔了怎么办？使用 Reflog 救命
万一 Rebase 操作搞砸了，或者合并后效果不理想，是不是就完蛋了？并不是。Git 有一个“时光机”叫做reflog。
git reflog命令会显示 HEAD 指针的所有移动记录。每一次提交、合并、rebase、reset 操作都会被记录下来。找到你开始 Rebase 之前的那个状态（通常显示为rebase -i (start)之前的一次操作），记下它的哈希值或引用（如HEAD@{2}）。
然后，简单地使用git reset --hard HEAD@{2}（将2替换成对应的数字）就可以将你的分支硬重置到 Rebase 之前的状态。这是一个非常强大的回退工具，能让你在误操作后从容恢复。
6. 进阶技巧：更复杂的提交历史整理
掌握了基础合并后，你可以尝试一些更高级的操作，让你的提交历史像艺术品一样精致。
6.1 拆分提交
有时一个提交包含了两个不相关的修改，你想把它拆成两个独立的提交。这需要用到edit命令。
- 在交互式 Rebase 列表中，找到你想拆分的提交，将其命令从
pick改为edit。 - Rebase 过程会在应用这个提交后暂停。
- 运行
git reset HEAD~。这是一个混合重置，它会撤销提交，但保留所有更改在工作目录中。 - 现在，你可以选择性地添加文件到暂存区。例如，先把与功能A相关的文件
git add进去，然后git commit -m “feat: add A”。接着，再把与功能B相关的文件git add进去，然后git commit -m “feat: add B”。 - 完成拆分后，运行
git rebase --continue继续后续的 Rebase 步骤。
6.2 重新排序提交
在交互式 Rebase 的编辑界面里，你完全可以通过移动行来改变提交的顺序。比如，你把一个修复 Bug 的提交，移到引入该 Bug 的提交之前，这在逻辑上是不通的，Git 会在应用时产生大量冲突。但如果你把几个独立的、修改不同文件的提交调整顺序，通常可以顺利进行。这在你希望按逻辑主题而非时间顺序组织历史时很有用。
6.3 彻底删除提交
如果你想完全丢弃某个提交及其带来的所有更改，在交互式 Rebase 列表里，直接删除那一整行即可。或者，你也可以将命令改为drop。保存退出后，那个提交就会从历史中消失。这是一个破坏性操作，确保你真的不需要那些更改。
7. 与其它工作流的结合：让 Rebase 成为习惯
git rebase不是孤立使用的，它应该融入你日常的 Git 工作流中。
git pull --rebase代替git pull。git pull的默认行为是fetch+merge，这会在你的历史中产生一个多余的合并提交。而git pull --rebase则是fetch+rebase，它会将你的本地提交“变基”到远程分支的最新提交之上，从而保持历史是一条干净的直线。你可以通过git config --global pull.rebase true将其设为默认行为。
在特性分支开发中
- 从
main分支切出新分支feature/x。 - 在
feature/x上进行多次小提交。 - 在完成开发后、合并回
main之前，使用git rebase -i整理和合并提交。 - 切换到
main分支，拉取最新代码 (git pull --rebase)。 - 切换回
feature/x，执行git rebase main，将你的特性分支变基到main的最新提交上，解决可能出现的冲突。这确保了你的特性分支是可以干净合并的。 - 切换到
main，执行git merge feature/x（如果允许，可以使用--no-ff保留分支信息）。由于你已经 rebase 过，这通常是一个快进合并，非常干净。
这个过程确保了主分支的历史清晰、线性，并且每个合并进来的特性都经过了整理，易于追溯和回滚。
经过这样一番操作，你的 Git 提交历史将不再是杂乱无章的日记草稿，而是一份结构清晰、目的明确的工程日志。这不仅仅是个人习惯的优化，更是在团队协作中传递专业性和尊重的一种方式。刚开始可能会觉得步骤繁琐，但一旦形成肌肉记忆，它将成为你开发流程中自然而然、不可或缺的一环。记住，工具是为人服务的，大胆去用，谨慎操作，遇到问题还有reflog这把万能钥匙。
