带过不少刚接触 Git 的新人，几乎每轮都会被同一个问题问住：“commit 和 merge 到底啥区别？不都是把代码整理到一条记录里吗？”刚开始我还会耐心解释，后来我发现，这个问题背后其实藏着一个很深的误解：很多人把 commit 当成“保存按钮”，把 merge 当成“把文件拼起来”，结果一到实际操作——比如合并完之后为什么还要再提交一次？——整个人就懵了。Git 里的 commit，本质是把你当前仓库的完整状态变成一个不可变的对象，写进本地历史；而 merge，本质是把两条已经分叉的历史重新整合成一条时间线，并且通常会以一个新的提交节点来收尾。一个是“写记录”，一个是“整合记录”，这两件事的服务对象、触发条件、产物都不一样。这篇文章我打算从底层原理、命令实操到团队协作，把这层关系彻底拆开讲清楚。
1. commit的底层本质：它不是在“保存”，而是在给仓库拍照
1.1 一次commit到底干了什么
很多教程会把 git commit 解释成“保存进度”，这个说法害了不少人。因为它暗示 commit 和“Ctrl+S”差不多，于是有人改一行代码就 commit 一次，或者把所有改动攒到最后一次提交，两者都不对。要理解正确姿势，得先掀开引擎盖看一眼 Git 到底是怎样存东西的。
在你执行 git commit 之后，Git 会依次做三件事。第一，把暂存区里所有文件的当前内容打包成树对象（tree object），树对象你可以理解为一棵“目录快照树”，它记录了每个文件对应内容的哈希引用。第二，生成一个提交对象（commit object），里面包含这棵树对象的哈希、父提交的哈希（第一次提交没有父提交）、作者姓名和邮箱、提交者姓名和邮箱、时间戳，以及你写的提交信息。第三，把当前所在分支的引用（比如 main 或 feature/login）移动到刚生成的这个提交对象上。
这里最关键的一点是：commit 保存的是“完整快照”，不是一个补丁文件。Git 展示 diff，是在前后两个相邻 commit 的树对象之间做比对算出来的。这就是为什么你可以毫无心理负担地 checkout 到三个月前的某次 commit，因为那个快照还在仓库里。凡是把 commit 理解为“存了哪些改动”的人，在碰到 cherry-pick、rebase 这些动作时都会产生认知障碍。
有一个经常出现的操作顺序问题：你先改了文件，然后直接 git commit，结果发现提交的内容里根本没有这次改动。原因很简单——git commit 默认只提交暂存区里的东西。Git 的流程是“工作区改文件 → git add 把内容放进暂存区 → git commit 把暂存区内容变成一次提交”。跳过 add，就等于拍了一张没有新内容变化的“空照片”。我见过太多新人在这一步翻车，建议养成习惯：每次 commit 前先 git status 看一眼，确认绿色区域的变更符合预期。
1.2 本地写记录，不需要联网，但要先交代身份
很多人以为 commit 和“提交到远程仓库”是一回事，于是问“为什么不联网就不能 commit”。澄清一下：commit 是纯本地操作，根本不需要和远程仓库沟通。你敲下 git commit，改动进的是本地仓库的 .git 目录；只有执行 git push 的时候，才把本地已有的提交同步到远端。理解了这一点，你还得懂为什么 Git 强制要求配置 user.name 和 user.email——因为每次 commit 都要把“谁写的”写进提交对象，校验的时候读取的是本地 Git 配置，不是服务器账号，更不是登录凭证。
新环境里最容易碰到的报错就是这个：
$ git commit -m "feat: add login page" *** Please tell me who you are. Run git config --global user.email "you@example.com" git config --global user.name "Your Name"解决方式很简单：
git config --global user.name "Your Name" git config --global user.email "you@example.com"注意 user.email 不要求是真实邮箱，但它会成为历史的一部分。如果你在一个项目里用了错误的身份提交，要改起来非常麻烦，因为提交对象里包含作者信息和提交者信息，改了几乎等于重写历史。我建议在入职新电脑第一天就配好全局身份，免得三个月后历史里全是“Unknown”。
1.3 修正提交、整理提交、撤销提交：commit 的三种衍生操作
commit 本身是可以被“操作”的，这引出了一系列高频命令，每个都值得在理解“commit 是快照对象”的基础上再学。
- git commit --amend：把最后一次提交“换掉”。它会生成一个新的提交对象，替换掉原来的对象，换的时候可以补充漏掉的文件，也可以修改提交信息。原理是：新对象继承原提交的树对象和父对象，再把新内容合并进去。重点在于——它只适合处理尚未推送到远程的提交；如果你 push 之后再 amend，本地历史和远程不一致，下一次 push 会被拒绝，或者产生一个你根本不想看到的分叉。
- git commit --allow-empty：在某些 CI 流程里需要触发流水线，但代码没有变化，可以生成一个“空提交”。
- git reset --soft HEAD~1：撤销最近一次 commit，但保留所有改动在工作区。常用于“提交错了，想拆开重新提交”。
- git rebase -i：交互式整理多次 commit，可以合并、重排、拆分。它的现实意义是：在把一个分支并回主线之前，先把这条分支上的几十个小提交整理成几个清晰的大提交，让合并后的历史更好读。
你会发现上面这些命令全部围绕“提交链”在做文章，没有一个涉及跨分支的整合。在进入 merge 之前，先把这层“提交链是线性的、可整理的”概念立住，后面才不容易乱。
2. merge的底层本质：把两条历史拼回一条主线的三方协商
2.1 分叉，才是merge存在的理由
merge 做的事和一个日常意义上的“合并文件”完全不是一回事。一个新人如果只在“把两份文件拼起来”的层面理解 merge，遇到冲突必然会慌。真正的 Git merge，是只有在两条历史出现分叉时才会发生的高级操作。
举个例子。你从 main 的某个提交点 B 拉了一条分支 feature，主线继续走了两步 C、D，你的 feature 分支也走了两步 E、F。此时两条历史已经分叉，它们的共同祖先是 B。现在你切回 main 并执行 git merge feature，Git 会做一次三方（three-way）合并：拿共同祖先 B 作为基准，分别对比 B 到主线最新点 D 的差异，以及 B 到 feature 最新点 F 的差异，然后尝试把两边的差异同时应用到最终结果上。
如果没有分叉会怎样？比如 feature 从 B 分出去后，主线一直停在 B 原地，你直接 merge feature，Git 就没有必要“合并”，它只要把 main 的引用从 B 一路推进到 F 就行了。这就是 fast-forward（快进）合并。很多初学者在这里会困惑：“我明明执行了 merge，为什么没有 merge commit？”原因就在这——没有分叉，就不需要产生新的合并节点，直接往前推指针即可。只有两边的历史真正分道扬镳，Git 才会做那一次三步协商，并生成一个合并提交来收尾。
2.2 合并提交：拥有多个父节点的特殊commit
一个 merge 操作完成后，Git 默认会生成一个新的提交对象，这个对象就叫合并提交（merge commit）。它和普通 commit 长得非常像，唯一的关键差异是父提交的数量：普通 commit 只有一个父提交，而合并提交通常有两个。打开一个合并提交，你会看到类似下面这样两条父记录：
git cat-file -p <merge_commit_hash> parent <第一父提交哈希> parent <第二父提交哈希> tree <树对象哈希> message "Merge branch 'feature/login' into main"这个结构意味着什么？意味着合并提交是历史拓扑里的“汇聚点”，它同时指向两条前序历史。也正是这个原因，你可以通过 git log --graph 看到真实的合并形状：两条线在一个点汇合，然后继续往前走。所以你问我“commit 和 merge 到底有什么区别”，准确答案是：merge 不是一个与 commit 互斥的操作，它本身也是用 commit 实现的——一个拥有多个父提交的特殊 commit。
理解了这一点，你就能看懂两个常用开关了。一是 --no-ff：即使这次合并本来可以 fast-forward，也强制生成一个合并提交，保住“这里发生过一次功能合并”的历史语义；二是 --squash：把 feature 分支上的多个提交压缩成一个普通提交，合并方式不再是“生成合并提交”，而是“再造一个单父提交”，完全抛弃分支原有历史。看到没有，同样一个 merge 命令，兜兜转转还是在调 commit 的形态。
2.3 冲突：不是错误，是三方协商的“语言”
merge 过程中最让新人发怵的就是冲突（conflict）。我先给一个定心丸：冲突一点都不罕见，也不意味着代码坏掉了。它只是说明 Git 在三方合并时发现同一行位置出现了两处“互不相让”的修改，无法自行判断哪边是最终答案，于是把问题交给你决策。
冲突发生时，文件里会出现这种标记：
<<<<<<< HEAD console.log("main version"); ======= console.log("feature version"); >>>>>>> feature/loginHEAD 代表当前分支的内容，feature/login 代表被合并分支的内容。你要做的不是“删掉标记”，而是认真看两边的代码，决定保留哪一边、要不要两边都留，然后手动把最终内容写好，删掉三段标记。之后执行 git add 把文件标记为已解决，再执行 git commit 形成一个合并提交。
这里就是很多人的顿悟时刻：原来解决冲突的最后一步，还是 commit。所以“commit 是 merge 的前提与收尾”这句话不是抽象道理，而是字面意义上的流程。再补一句关于 JSON 的：网上有个高频热搜叫 json merge conflict，我见过有人以为 Git 对 JSON 有特殊处理，其实没有。Git 只做基于行的文本合并，它完全不懂 JSON 结构，两个分支都改了同一个 JSON 文件同一区域，一样会出冲突，解决后你也得照常 add + commit。
3. 核心区别对照：一张表加两条实战判据
3.1 六个维度拆开对比
把底层讲完之后，我用一张表把两者从六个维度直接摊开：
| 对比维度 | commit | merge |
|---|---|---|
| 动作目标 | 把当前仓库状态固化成一个不可变快照 | 把两条分叉的历史整合成一条时间线 |
| 操作对象 | 单个分支上的提交链 | 两个分支及它们共同祖先的历史拓扑 |
| 触发条件 | 完成一个可提交的工作单元 | 分支之间存在分叉且需要整合 |
| 主要产物 | 一个普通提交对象 | 一个合并提交对象（或 fast-forward 引用前移） |
| 是否必然产生新提交 | 是，必然产生 | 分叉时产生合并提交；可 ff 时不强制产生 |
| 冲突可能性 | 极低，几乎不会 | 较高，同一区域被双方修改时必然冲突 |
这张表最容易看穿的一个误区是：二者都不是“上传代码”，都是本地操作。真正和远程有关系的是 push 和 pull。把 commit/merge 放在本地层面理解，很多“怎么合并完还要提交”的疑问都会自然消失。
3.2 快速判断一个动作到底是commit还是merge
实际开发里你不需要背概念，遇到一个 Git 动作时，问自己三个问题基本就能判断：
- 它是否创建了一个新的提交对象？如果没有，那既不是 commit 也不是 merge，多半是 reset、checkout、stash 这类引用或工作区操作。
- 如果创建了提交对象，它有几个父提交？两个及以上，必是 merge 或其回显；一个，就是普通 commit。
- 它是否改变了不同分支引用之间的拓扑关系？比如 old main 指向 A，merge 后 main 与 feature 在拓扑上汇合——这就是 merge；如果只是自己分支上多了一个 commit 节点，那是 commit。
这个判据在排查问题时特别管用。比如有人贴出 git log --graph 问你“这里为什么有个分叉”，你只要看到带两个父提交的节点，就能立刻回答这是合并产生的。
3.3 commit、merge、rebase三者的边界
既然热搜榜上 merge rebase 常年是兄弟话题，我就在这里顺便把三者的边界理清楚。
rebase 的全名是“变基”，它在做的事是把一条分支上的所有提交“摘下来”，在另一条分支的顶端逐个重新拼接。rebase 完，历史变成一条干净直线，所有被搬运的提交对象哈希全部改变，因为它们的父提交变了。所以，rebase 本质上不是合并，它是对历史链的重塑工具。merge 则保留两条前序历史，并生成一个汇聚点。而 commit 是这两者的共同原子：没有 commit，你既不能合并，也不能变基。
选择规则先给一个通用版本：如果你在操作自己的、尚未推送到远端的提交链，用 rebase 整理会更干净；如果你在操作多人共享的分支，强烈建议使用 merge，因为合并节点能保留“分工协作的真实痕迹”，而 rebase 重写历史的操作会推翻别人已经基于旧提交建立的参照点。
4. 从一次真实操作链路看commit与merge的配合
4.1 一个完整而典型的分支提交合并过程
理论说得再多，不如亲手走一遍。假设要开发登录功能，整个链条大概是这样的：
# 1. 从 main 切出功能分支 git checkout -b feature/login main # 2. 在功能分支上做小步提交 git add login.html git commit -m "feat: add login page" git add login.js git commit -m "feat: add login logic" # 3. 功能开发完，切回主线，先把主线更新到最新 git checkout main git pull # 4. 把功能分支合并回主线 git merge feature/login # 5. 推送到远端 git push注意第 4 步的语义：执行 merge 时，如果 main 在你切出分支后有新提交，Git 会走三方合并并产生一个合并提交；如果 main 一直没动，Git 会 fast-forward，直接把 main 指向 feature 最新提交。无论哪种，你都可以用 git log --graph --oneline 看到结果——有分叉形状的是真合并，直线前进的是 ff。
我在带新项目时，会让每个人把这些命令在命令行里至少完整跑三遍。因为只有亲手看过“普通提交节点”和“合并提交节点”在日志里的不同长相，才能在脑子里建立正确模型。
4.2 合并错了怎么办：回退merge的不同思路
热搜里有个 “idea中如何回退merge操作”，其实无论是在 IDEA、VS Code 还是在命令行，回退 merge 的关键反而不在界面按钮，而在你理不理解它的父提交结构。不同场景的回退方式差很多：
- 合并后还没提交，比如冲突解决到一半发现方向错了：执行 git merge --abort，它会直接退回到 merge 之前的状态，干净利落。
- 合并已经结束、也生成了合并提交，但还没 push：用 git reset --hard <merge前提交哈希>，让 main 重新指向合并前的位置。使用前务必确认没有其他人基于这个合并提交开发。
- 合并已经 push 到共享仓库：不要用 reset，要用 git revert -m 1 <合并提交哈希>。-m 1 的意思是“保留第一父提交的线路、撤销第二父提交带来的改动”。它会产生一个新的反向提交，把 feature 的改动从 main 上“倒回去”，同时保留历史中的合并记录。这样做的好处是不会重写共享历史，别人 pull 时不会遇到“历史不一致”的错乱。
IDE 里的可视化按钮本质上就是在帮你执行这套 Git 命令，但如果选择按钮的人不明白 merge 有父提交、不明白 reset 和 revert 的区别，很容易点出大事故。我建议：团队开发中，回退合并一律先问一个问题——这个合并提交是否已经被别人 pull 过了？被 pull 过就只允许 revert，哪怕历史难看一点。
4.3 合并方法的选择：直接merge、rebase后再merge、还是squash
不少代码托管平台在拉取合并请求（Pull Request / Merge Request）时都给你三个按钮：Create a merge commit、Squash and merge、Rebase and merge。它们的差别恰好对应我们前面讲的概念：
- Create a merge commit：保留双方所有提交流水账，并在合并时产生一个汇聚点。优点是可追溯性最强，缺点是好几个人的小提交全堆进主线。
- Squash and merge：等价于 git merge --squash。把分支上所有提交压缩成一个普通提交，再放到主线。历史非常干净，但代价是分支细节全丢，以后想追溯“这个功能内部开发过程”就难了。
- Rebase and merge：先对分支做 rebase 到主线顶端，再快进合并。最终历史是直线，分支上每个提交独立保留，既干净又有一定细节，但 rebase 会改写原提交哈希，一旦分支已被共享则风险较高。
我给团队的建议是：默认用 Create a merge commit，保持历史真实；如果是个人开发者的小功能，可以用 squash 减少噪音；线上热修复这种需要精确追溯到具体提交的场景，就别用 squash。
4.4 commit --amend的误用与正用
热搜里还有个问题叫 git commit --amend怎么使用，这里单独讲，因为它正好是“commit 可被改写”的最好例子。
正用：你刚才 commit 完发现少了一个文件、或者把提交信息写错了，而且这个提交还没有 push，此时 git commit --amend 就是后悔药。它会把暂存区里的新改动连同原来最后一次提交一起合成一个新的提交对象。我常用的套路是：
git add 漏掉的文件 git commit --amend --no-edit--no-edit 表示仍然沿用原提交信息，我只补文件不重写 message。
误用：提交已经被 push 到共享分支，你本地又 amend 了一次，然后强制推送，于是远端历史被改写，团队里其他人的 checkout 全部失去参照。更为隐蔽的误用是对 merge commit 执行 amend。前面讲了合并提交有多个父提交，amend 这种“替换当前提交”的操作会把它变成普通提交还是保留多父结构？答案是不确定且不推荐。你永远不知道为什么历史里出现了一个“带两个父提交但又不属于原合并”的怪节点。所以我的铁律是：push 之后的提交，一律不 amend；merge 产生的提交，连本地也尽量不 amend，真要用就先把分支状态备份好。
5. 团队协作中的提交与合并心法
5.1 提交粒度与信息：少给merge挖坑
团队协作时，commit 的写法直接决定 merge 的体验。一个“改了几十个文件、信息却只写一句 update”的提交，在 merge 冲突场景下几乎无法定位任何历史责任；反过来，一次提交只解决一个逻辑问题、信息采用约定式提交格式，比如 feat:、fix:、refactor:、docs:，合并时哪怕出现冲突，你也能立刻知道每段代码属于哪个功能、由谁负责。
我的实践是要求团队成员把“一次提交 = 一个可描述的逻辑单元”当作前提，而不是把“今天的东西都备份一下”。备份可以用 stash 或临时分支完成，commit 是给后续协作者看的公共资产。这条心法听起来抽象，但一旦落地，merge 冲突从“到处乱糟糟”变成“双方在明确的两个提交上对话”，效率提升是很明显的。
5.2 什么情况下值得保留merge节点
快速合并（fast-forward）确实历史干净，但代价是“功能从哪一刻进入主线”的语义消失了。在主干分支上，如果每个功能都是以一个 ff 直线推进，三个月后想找“登录功能是哪次合入的”就得靠提交信息猜；如果当时用 --no-ff 生成了一个 merge commit，git log --first-parent 就能直接列出主干上每一次合并点，项目的演进脉络清晰得多。
反之，两个功能分支之间频繁互通代码产生的临时 merge 节点，往往是没有价值的噪音，应该用 rebase 尽量避免。我的粗粒度原则：与主干交汇时尽量保留 merge 语义，分支私聊时尽量用 rebase 整理。这个原则可以让 log --graph 既不爆炸，也保留主干的时间线故事。
5.3 高频踩坑盘点：关于commit与merge的“为什么”
最后盘一盘这些年最常被人踩的坑，每一个都能追溯到没分清 commit 和 merge：
- 以为 commit 等于上传，所以 commit 完不 push，第二天换电脑发现“代码丢了”。其实 commit 只在本地，换机器必须 push。
- 没配置身份信息就 commit，报错后干脆用别人名字，结果历史里责任人张冠李戴。
- 冲突解决完忘记 git add 就直接 commit，要么提交不成功，要么把“仍带冲突标记的文本”提交进仓库，直接破坏构建。
- 看到 merge commit 就以为是自己多提交了一次，尝试用 reset 删掉它，结果把整个功能分支改动都删没了。
- 在共享分支上 push 后 amend，远端拒绝推送，然后又用 force push 覆盖了同期同事的提交——这是最严重的一类事故。
- 在 IDE 里点错了“Revert Merge”的 parent 编号，把主线的发展方向给回退掉了，代码状态瞬间穿越回合并前。
排查这些问题的通用套路也很简单：先 git log --graph --oneline --decorate 打开一张历史拓扑图，然后问两个问题——这个节点有几个父提交？这个节点是不是本地还没有被他人引用的私有提交？回答完这两个问题，再去选 reset、revert、amend 还是 rebase，基本就不会点错了。
带团队这些年，我最大的体会是：Git 的命令记住不难，难的是大脑里能不能建立正确的“对象模型”。而 commit 与 merge 的差异，恰恰是这个模型里最核心的一块基石。你要是把所有 Git 问题都化到“普通提交节点”和“多父合并节点”这两个基本单位里去想，冲突、回退、amend、rebase 这些概念就全都自动归位了。这也是为什么我在招新同学时，总喜欢先让他们用命令行把本文这条链路完整走一遍，再允许他们用图形界面。等这套直觉建立好了，用什么工具都已经不重要了。
