1. 从一次尴尬的代码评审说起
上周，团队里一位刚入职不久的小伙伴在提交一个功能模块时，一口气推送了十几个提交记录。在代码评审会议上，当大家打开提交历史，试图理解这个功能的演进脉络时，所有人都沉默了。历史记录里充斥着诸如“修复一个拼写错误”、“再改一下格式”、“忘了加个分号”、“测试一下”、“真的最后一次修改”这样的提交信息。整个功能的逻辑被拆得七零八落，想回溯某个关键决策点或者理解代码的完整意图变得异常困难。这场景，相信不少带过新人的技术负责人或者参与过协作开发的朋友都深有体会。
这恰恰引出了我们今天要深入探讨的核心操作：Git 如何合并多个 Commit。这绝不仅仅是一个简单的命令使用问题，它关乎代码仓库的整洁度、团队协作的效率，以及项目历史的可维护性。一个清晰、线性的提交历史，就像一本写得很好的项目日志，能让后来的维护者（包括三个月后的你自己）快速理解代码的来龙去脉。相反，一堆杂乱无章的微型提交，则像一本被撕碎又胡乱粘起来的日记，阅读成本极高。
简单来说，合并 Commit 的核心目的，是把一系列相关的、小步的更改，整合成一个或少数几个逻辑完整、信息明确的提交。这个过程在 Git 中通常通过git rebase -i（交互式变基）来实现。但知其然更要知其所以然，接下来，我会结合多年实战经验，不仅告诉你命令怎么敲，更会剖析何时该用、怎么用好，以及那些教程里很少提及的“坑”和最佳实践。
2. 理解合并 Commit 的核心理念与适用场景
在动手操作之前，我们必须先统一思想：为什么要合并 Commit？合并 Commit 不等于“篡改历史”，而是一种“整理历史”的负责任行为。它主要服务于以下几个核心场景：
2.1 提交历史的原子性与可读性一个理想的提交应该代表一个完整的、可工作的逻辑变更单元。比如“实现用户登录功能”、“修复订单计算中的溢出漏洞”。如果你的“实现登录功能”被拆成了5个提交：添加路由、创建控制器、编写表单、连接数据库、添加样式，那么每个提交本身都无法独立编译或运行，这就破坏了原子性。合并它们，形成一个“添加用户登录功能”的提交，历史立刻清晰。
2.2 准备合并（Pull Request / Merge Request）这是最常用的场景。在将特性分支合并回主分支（如main或master）之前，清理分支上的提交历史是一项基本礼仪。想象一下，你向开源项目提交 PR，里面包含20个“WIP”（Work In Progress）和“fix typo”的提交，维护者大概率会要求你整理干净后再提交。一个整洁的 PR 包含1个或少数几个意义明确的提交，极大降低了评审者的心智负担，也提高了被接纳的概率。
2.3 修复之前的提交有时我们提交后才发现有个小错误，比如漏了文件或者有个拼写错误。常见的做法是直接再提交一次“修复XX错误”。但更好的做法是，将这个修复性的提交合并到它所要修复的那个原始提交中去，使得历史中不留下“修补丁”的痕迹。这需要通过交互式变基的“fixup”或“squash”操作来实现。
2.4 分支整理与重构在进行长期开发或复杂重构时，分支上可能会积累大量实验性、临时性的提交。在功能稳定后，将这些提交合并、整理，形成清晰的重构步骤，对于后续维护至关重要。
注意：一个重要的原则是：只整理尚未推送到远程共享仓库的本地提交历史。一旦提交已经被推送到远程（尤其是公共分支），强行重写历史（
git push -f）可能会给其他协作者带来灾难。因此，合并 Commit 的最佳时机是在本地完成开发、准备推送并创建 PR 之前。
3. 核心武器：交互式变基（git rebase -i）详解
git rebase -i是完成 Commit 合并的瑞士军刀。这个命令会打开一个交互式界面，让你重新排序、合并、编辑甚至删除一系列提交。它的威力巨大，但使用前务必理解其工作流程。
3.1 命令基础与界面解读假设我们想整理最近4个提交，可以执行：
git rebase -i HEAD~4或者，如果你想基于某个分支（如main）来整理当前分支的所有独特提交：
git rebase -i main执行后，Git 会打开默认编辑器（如 Vim、VSCode 集成终端等），显示类似如下的内容：
pick a1b2c3d 添加用户登录页面框架 pick e4f5g6h 实现登录表单前端验证 pick i7j8k9l 连接后端登录API接口 pick m1n2o3p 修复登录按钮点击无效的bug # Rebase x1y2z3a..m1n2o3p onto x1y2z3a (4 commands) # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # d, drop = remove commit # # These lines can be re-ordered; they are executed from top to bottom.这个列表按时间顺序从旧到新排列。最上面（a1b2c3d）是最早的提交，最下面（m1n2o3p）是最新的提交。每一行由三部分组成：命令、提交哈希值（缩写）、提交信息。
3.2 关键命令解析
- pick (p): 保留该提交，不做任何改动。这是默认命令。
- reword (r): 保留该提交的更改内容，但允许你修改提交信息。保存退出编辑器后，Git 会立即停下来让你重写信息。
- edit (e): 保留该提交，但暂停变基过程，允许你修改这个提交的内容（比如增删文件）。完成后用
git commit --amend，然后用git rebase --continue继续。 - squash (s):“压缩”。将该提交合并到前一个提交中。执行后，Git 会暂停，让你为合并后的新提交编辑一个全新的提交信息。这个命令会保留被合并提交的信息作为编辑时的参考。
- fixup (f):“修复”。与
squash类似，将该提交合并到前一个提交中。但关键区别是，它会直接丢弃当前提交的提交信息，使用前一个提交的信息。这对于合并那些“修复拼写错误”、“修正格式”之类的提交特别方便，无需再编辑信息。 - drop (d): 直接丢弃（删除）这个提交。
3.3 一个完整的合并操作示例回到开头的例子，我们想把后三个提交都合并到第一个提交中，形成一个完整的“实现用户登录功能”提交。
启动交互式变基：
git rebase -i HEAD~4在编辑器中修改命令： 将后三行的
pick改为squash或fixup。如果你想在合并时重新撰写提交信息，用squash；如果后三个提交信息无用，直接用fixup。pick a1b2c3d 添加用户登录页面框架 squash e4f5g6h 实现登录表单前端验证 squash i7j8k9l 连接后端登录API接口 fixup m1n2o3p 修复登录按钮点击无效的bug这里我对最后一个修复性提交使用了
fixup，因为它“修复按钮bug”的信息不需要保留在新提交信息里。保存并关闭编辑器。Git 开始执行变基操作。
编辑新的提交信息（如果使用了
squash）： 由于我们使用了squash，Git 会再次打开编辑器，显示类似下面的内容：# This is a combination of 4 commits. # This is the 1st commit message: 添加用户登录页面框架 # This is the commit message #2: 实现登录表单前端验证 # This is the commit message #3: 连接后端登录API接口 # This is the commit message #4: 修复登录按钮点击无效的bug # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit.你可以删除所有以
#开头的行，重新编写一个清晰、完整的提交信息，例如：实现用户登录功能 - 新增登录页面视图组件与路由 - 完成表单前端输入验证（邮箱、密码格式） - 集成后端认证API，处理登录请求与令牌存储 - 修复登录按钮状态管理问题保存退出后，Git 会完成变基，你的本地分支历史中就只剩下一个逻辑清晰的提交了。
4. 高级策略与实战中的疑难杂症
掌握了基本操作，我们来看看更复杂的情况和那些容易踩坑的地方。
4.1 处理合并冲突变基过程本质上是重新应用提交，因此在重新应用某个提交时，如果它的修改与当前代码状态冲突，就会发生合并冲突。这是使用rebase时最常见也最需要小心的问题。
- 冲突发生时的表现：Git 会暂停变基，在命令行提示
CONFLICT (content): Merge conflict in <file-name>，并告知你当前正在应用哪个提交。 - 解决冲突的步骤：
- 不要慌。Git 已经暂停了，给你时间处理。
- 使用
git status查看哪些文件有冲突。 - 手动打开冲突文件，你会看到
<<<<<<< HEAD，=======，>>>>>>> commit-hash这样的标记。这分别代表当前分支的代码（HEAD）、分割线、和正在应用的提交的代码。你需要决定保留哪一部分，或者进行融合，然后删除这些标记。 - 解决完所有冲突文件后，使用
git add <file>或git add .将解决后的文件标记为已解决。 - 最后，执行
git rebase --continue让 Git 继续变基过程。 - 如果中途想放弃整个变基操作，回到变基前的状态，可以执行
git rebase --abort。
提示：一个减少冲突概率的技巧是，在开始一个功能开发前，先通过
git pull --rebase将主分支的最新变更“变基”到你的分支底部，让你的新提交都基于最新的代码，这样在最后整理提交时冲突会少很多。
4.2 只合并部分提交有时你不想合并所有提交，比如你有5个提交，只想合并中间的第2、3、4个。这时你需要更精细地操作rebase -i的编辑列表。
- 执行
git rebase -i HEAD~5。 - 在列表中，将第3、4、5行（假设你想合并3、4、5到2）中你想“被合并”的提交的命令改为
squash或fixup。注意顺序：squash和fixup总是合并到它上方最近的一个pick提交。
这样，提交3和4就会被合并到提交2中，提交1和5保持不变。pick a1b2c3d 提交1：功能A pick b2c3d4e 提交2：功能B（这是基准） squash c3d4e5f 提交3：功能B的补充 fixup d4e5f6g 提交4：修复功能B的bug pick e5f6g7h 提交5：功能C
4.3 修改更早的历史（非最近N个提交）HEAD~N只针对最近的提交。如果你想修改历史中某个特定提交（比如一周前的），你需要找到它的“父提交”的哈希值。一个更通用的方法是使用git rebase -i <commit-hash>^，其中<commit-hash>是你想修改的提交的前一个提交。你可以通过git log --oneline --graph来查看和定位提交哈希。
4.4 使用git merge --squash的替代方案如果你在一个特性分支上开发完毕，只是想把它所有的更改压缩成一个提交再合并到主分支，有一个更简单直接的方法：
# 切换到主分支 git checkout main # 拉取最新代码 git pull # 执行 squash 合并 git merge --squash your-feature-branch # 此时，所有更改都在暂存区，但尚未提交 git commit -m “完整的特性描述：实现了XXX功能”这个方法不会重写特性分支的历史，而是在合并时一次性将所有差异打包成一个新提交。它的优点是操作简单、不会影响特性分支本身的历史。缺点是失去了特性分支内部的演进细节，且如果合并后发现问题，需要回滚整个大提交。
5. 集成开发环境（IDE）中的可视化操作
对于不习惯命令行的开发者，现代 IDE 如Visual Studio Code和IntelliJ IDEA都提供了强大的 Git 图形化界面，可以更方便地进行提交合并。
5.1 Visual Studio Code
- 安装 GitLens 或使用内置的 Git 功能。
- 在“源代码管理”视图中，右键点击某个提交，可以选择“将提交变基到...”。
- 更直观的方法是使用“Git Graph”扩展，它提供了一个可视化的提交网络图。在图上，你可以直接通过拖拽、右键菜单来进行交互式变基、压缩提交等操作，界面会引导你完成命令编辑和冲突解决。
5.2 IntelliJ IDEAIDEA 的 Git 集成度非常高。
- 打开
Git -> Log视图。 - 在提交历史列表中，选择你想要合并的一系列提交（按住Ctrl多选）。
- 右键点击，选择
Squash Commits...。 - IDEA 会弹出一个对话框，让你编辑合并后的新提交信息，确认后即可完成操作。整个过程无需手动编辑
rebase -i的文件，非常直观。
个人体会：虽然图形化工具降低了门槛，但我强烈建议开发者也要理解背后的命令行原理。一方面，在服务器环境或某些自动化脚本中，你只能使用命令行；另一方面，当图形化工具操作出现意外（如复杂冲突）时，理解底层命令是你解决问题的最后保障。我通常的 workflow 是：在 IDEA 里进行日常的提交、拉取、推送，但在进行重要的历史整理（如准备 PR 前）时，我会切换到终端使用
git rebase -i，因为我对每一步的控制感更强。
6. 团队协作规范与提交信息写作指南
合并 Commit 最终是为了产出清晰的历史，而清晰的历史离不开好的提交信息。这里分享一些被广泛认可的约定。
6.1 提交信息格式（Conventional Commits）推荐使用一种结构化的格式，例如：
<type>(<scope>): <subject> <body> <footer>- type: 提交类型，如
feat（新功能）、fix（修复bug）、docs（文档）、style（格式）、refactor（重构）、test（测试）、chore（构建/工具变动）。 - scope（可选）：影响范围，如模块名。
- subject: 简短描述，不超过50字符，使用祈使句现在时态（如“Add”而不是“Added”或“Adds”）。
- body（可选）：详细描述，说明动机、与之前行为的对比。
- footer（可选）：如关联的问题跟踪ID（JIRA Issue, GitHub Issue）。
例如，合并后的登录功能提交信息可以写成：
feat(auth): implement user login functionality - Add login page component with route `/login` - Implement front-end form validation for email and password - Integrate with backend authentication API - Store and manage auth token in localStorage Closes #1236.2 团队工作流建议
- 特性分支策略：每个新功能或修复都在独立的分支上进行。
- “早提交，常提交”：在本地分支上，鼓励小步快跑，频繁提交。这有利于分步备份和试验。
- “整理后再推送”：在将本地分支推送到远程并创建 PR/MR 之前，务必使用
git rebase -i整理提交历史，使其清晰、原子化。 - 主分支保护：确保
main/master分支被保护，只能通过 squash merge 或 rebase merge 并入代码，禁止直接推送。这能保证主线历史的线性与整洁。
合并多个 Commit 是一个从“代码工匠”迈向“工程艺术家”的标志性技能。它要求开发者不仅关心代码是否能运行，更关心代码历史是否优雅、是否利于协作。刚开始可能会觉得有点麻烦，但一旦形成习惯，你会发现它带来的长期收益——清晰的历史、高效的评审、顺畅的回滚——远远超过那一点点整理的时间成本。下次提交前，不妨花几分钟看看你的提交列表，问自己一句：“如果我是三个月后的维护者，我希望看到什么样的历史？”
