笔记——深入探究 git 背后的 commit 重写机制 文章目录现场还原先说结论git commit --amend 不是原地修改从 commit 对象理解 amend一次 amend 操作背后发生了什么常见使用场景场景一修改最近一次提交说明为什么 amend 只能修改最近一次提交场景二修改倒数第二个 commit场景三合并多个零散 commit 整理成一个提交amend、reset、revert 的区别已经 push 后为什么要谨慎使用 amendamend 后旧 commit 去哪里了实际开发建议常用命令整理最后总结现场还原在日常开发中经常会遇到这样一种情况。代码写完之后执行提交gitadd.gitcommit-mfix bug提交完成后突然发现 commit message 写得太随意或者少提交了一个文件也可能是刚才的代码还有一个小地方需要修改。比如第一次提交之后通过下面命令查看提交记录gitlog--oneline结果如下a1b2c3d fix bug这时候发现提交信息不够清楚想改成fix customer address encoding issue第一反应可能是“那我再提交一次不就行了吗” 于是继续执行gitadd.gitcommit-mfix message这样确实可以产生一个新的 commit但是提交历史会变成b2c3d4e fix message a1b2c3d fix bug从代码结果来看问题可能已经解决了。但是从 Git 历史来看这两个 commit 并不一定都具有独立意义。第二个提交只是为了修正第一个提交并不是一个真正完整的业务变化。如果只是为了修正上一次提交那么更合适的方式应该是gitcommit--amend或者直接指定新的提交说明gitcommit--amend-mfix customer address encoding issue这就是git commit --amend最常见的使用场景。它表面上看是“修改最近一次提交”但从 Git 内部机制来看它并不是在原来的 commit 上直接修改而是重新创建了一个新的 commit 来替换原来的 commit。先说结论git commit --amend的作用可以理解为修改最近一次 commit并用一个新的 commit 替换掉原来的 commit。常见使用方式主要有三类。第一类是修改最近一次提交的 messagegitcommit--amend-m新的提交说明第二类是补充遗漏文件并且保留原来的提交说明gitaddxxx.javagitcommit--amend--no-edit这里的--no-edit表示不重新编辑 commit message只把当前暂存区里的内容合并进最近一次提交。第三类是修改最近一次提交里的代码。比如提交之后发现代码少了一个判断条件可以先修改代码然后执行gitadd.gitcommit--amend如果不想修改原来的提交说明也可以写成gitadd.gitcommit--amend--no-edit需要注意的是git commit --amend只能修改最近一次提交也就是当前HEAD指向的 commit。如果要修改倒数第二个或者更早的 commit就不能直接使用 amend而要使用交互式 rebasegitrebase-iHEAD~n比如修改倒数第二个 commit可以执行gitrebase-iHEAD~2然后根据需要把对应 commit 前面的pick改成reword或edit。git commit --amend 不是原地修改刚开始理解 amend 时很容易把它理解成“在原来的 commit 上改一下”。比如现在有一个提交历史A --- B ^ HEAD执行下面命令后gitcommit--amend-mnew message直觉上好像是把 B 的提交信息改掉了。但实际上Git 并不会原地修改 B而是创建了一个新的 commit B’然后让当前分支指向 B’执行前 A --- B ^ HEAD 执行 amend 后 A --- B ^ HEAD原来的 B 并不是被直接修改了而是被新的 B’ 替换掉了。所以 amend 之后再次查看提交记录会发现 commit id 发生了变化。这也是为什么说 amend 本质上是一种 commit 重写操作。从 commit 对象理解 amend想理解为什么 amend 后 commit id 会变化需要先理解 Git 中的 commit 对象。在 Git 里一个 commit 不只是保存代码快照它还包含 tree、parent、author、committer、message 等信息。可以通过下面命令查看当前 commit 的内部结构gitcat-file-pHEAD可能会看到类似结果tree 6f2b8d4c1f5a0c9b... parent 2d4f8a8c9e1b3f7... author zhangsan zhangsanexample.com 1710000000 0800 committer zhangsan zhangsanexample.com 1710000000 0800 fix bug这里的tree可以理解为当前项目目录结构和文件内容的快照parent表示当前 commit 是基于哪个父 commit 产生的author是代码作者committer是真正执行提交动作的人message就是提交说明。Git 的 commit id 不是随机生成的而是根据 commit 对象内容计算出来的哈希值。也就是说只要 commit 对象里的内容发生变化commit id 就会变化。即使文件内容没有变只是修改了 commit messagecommit 对象本身也已经变了所以 commit id 一定会重新生成。例如原来的提交是a1b2c3d fix bug执行gitcommit--amend-mfix customer address encoding issue之后可能变成e4f5g6h fix customer address encoding issue这里不是a1b2c3d这个 commit id 被修改成了e4f5g6h而是旧 commit 仍然存在过只是当前分支已经不再指向它。Git 新建了一个 commit然后把当前分支指针移动到了新的 commit 上。一次 amend 操作背后发生了什么假设当前提交历史是A --- B ^ main HEAD现在执行gitcommit--amend-mnew messageGit 大致会做几件事先读取当前HEAD指向的 commit也就是 B然后拿到 B 的 parent也就是 A接着根据当前暂存区内容生成新的 tree。如果 amend 前没有新的暂存内容那么新的 tree 可能和 B 原来的 tree 一样如果 amend 前执行过git add xxx.java那么新的 tree 就会包含这些新暂存的修改。随后 Git 会创建一个新的 commit。这个新 commit 的 parent 仍然是 A但是它的 message、committer 时间、tree 等信息可能已经发生变化因此 commit id 也会重新计算。最后 Git 会把当前分支从 B 移动到 B’A --- B ^ main HEAD旧的 B 不再被当前分支引用这就是 amend 背后的 commit 重写过程。常见使用场景场景一修改最近一次提交说明最常见的场景是修改最近一次提交说明。比如一开始提交得比较随意gitcommit-mfix查看日志gitlog--oneline结果是a1b2c3d fix如果这个提交说明太简单不利于后续维护可以执行gitcommit--amend-mfix customer address encoding issue再次查看日志时可能变成e4f5g6h fix customer address encoding issue可以看到commit message 变了commit id 也变了。第二个常见场景是补充遗漏文件。比如第一次提交时只提交了UserService.javagitaddUserService.javagitcommit-madd user service提交之后发现UserController.java忘记提交了。如果直接再提交一次gitaddUserController.javagitcommit-madd user controller提交历史会多出一个 commit。但从功能角度看UserService.java和UserController.java本来就属于同一个功能这时候可以把遗漏文件补进上一次提交gitaddUserController.javagitcommit--amend--no-edit最终提交历史里还是一个 commit但是这个 commit 里已经同时包含了UserService.java和UserController.java。第三个场景是提交后发现代码还有一个小问题。比如提交了用户校验逻辑之后发现少了一个空值判断可以修改代码后执行gitadd.gitcommit--amend--no-edit这样新的代码修改会被合并进最近一次提交提交说明保持不变。为什么 amend 只能修改最近一次提交git commit --amend的目标是当前HEAD所以它只能重写当前分支指向的最后一个 commit。假设提交历史如下A --- B --- C ^ HEAD此时执行gitcommit--amend只能修改 C因为 C 是当前HEAD。如果想修改 B就不能直接使用 amend。原因在于 C 的 parent 是 B如果 B 被改写成 B’那么 C 的 parent 也需要跟着变化。否则就会出现这样的结构A --- B --- C \ B也就是说修改中间某个 commit 后它后面的 commit 也必须重新生成一遍。这个过程已经不是单纯修改当前提交而是重写一段历史所以需要使用git rebase -i。场景二修改倒数第二个 commit假设当前提交历史是A --- B --- C ^ HEAD现在想修改 B也就是倒数第二个 commit可以执行gitrebase-iHEAD~2执行后会进入编辑界面内容大概是pick bbb222 commit B pick ccc333 commit C如果只是想修改 B 的提交说明把 B 前面的pick改成rewordreword bbb222 commit B pick ccc333 commit C保存退出后Git 会让你重新编辑 B 的 commit message。修改完成后Git 会继续把 C 应用上去最终历史会变成A --- B --- C这里不只是 B 变成了 B’C 也会变成 C’因为 C 的 parent 从 B 变成了 B’所以 C 自己也必须重新生成。如果不仅要修改提交说明还要修改 B 里的代码可以把pick改成editedit bbb222 commit B pick ccc333 commit CGit 会在 B 这个位置停下来。此时修改代码然后执行gitadd.gitcommit--amendgitrebase--continue可以这样理解git rebase -i负责把历史回放到你想修改的位置而git commit --amend负责修改当前位置的这个 commit。场景三合并多个零散 commit 整理成一个提交除了修改最近一次提交git rebase -i在实际开发中还有一个非常常见的使用场景功能分支合并前清理分支上的提交历史。比如开发一个功能时刚开始可能提交得比较随意a1b2c3d add user service b2c3d4e fix typo c3d4e5f add controller d4e5f6g fix null pointer e5f6g7h update code从开发过程来看这些提交是正常的因为写代码时经常会边写边修。但是从最终合并到develop或main的角度来看fix typo、fix null pointer、update code这类提交不一定有独立保留的价值。它们更像是开发过程中的中间修正而不是完整的功能变更。如果不清理直接合并主分支历史可能会变得很碎。以后排查问题时看到一堆fix、update、change很难快速判断每个 commit 的真实含义。所以在功能分支合并前可以使用交互式 rebase 把这些零散提交整理一下。假设当前功能分支是从develop拉出来的可以先更新远程引用gitfetch然后执行gitrebase-iorigin/develop这条命令的意思是把当前分支上相对于origin/develop新增的提交拿出来进入交互式整理界面。进入后可能看到pick a1b2c3d add user service pick b2c3d4e fix typo pick c3d4e5f add controller pick d4e5f6g fix null pointer pick e5f6g7h update code如果希望最终只保留一个比较完整的提交可以把后面的提交改成squash或fixuppick a1b2c3d add user service fixup b2c3d4e fix typo squash c3d4e5f add controller fixup d4e5f6g fix null pointer fixup e5f6g7h update code这里squash和fixup都可以把当前 commit 合并到前一个 commit 中区别是squash会保留提交说明并让你重新编辑最终 message而fixup会直接丢弃当前 commit 的 message只保留代码内容。实际开发中如果后面的提交只是“修错别字”“补文件”“修空指针”这类过程性修改通常用fixup就可以如果某个提交说明里还有值得保留的信息可以用squash。整理完成后最终提交历史可能会变成f6g7h8i add user service也可以整理成多个有意义的提交比如f6g7h8i add user base service g7h8i9j add user controller and validation这取决于这个功能本身是否适合拆分。如果一个分支只做了一件完整的事情压成一个 commit 会比较清晰如果这个功能里包含多个相对独立的变更整理成两三个有明确含义的 commit 会更合适。清理提交历史的目的不是强行把所有 commit 合成一个而是让每个 commit 都有清楚的意义。在整理过程中如果出现冲突需要正常解决冲突然后执行gitadd.gitrebase--continue如果中途发现整理错了也可以放弃本次 rebasegitrebase--abort如果这个功能分支已经推送到远程rebase 后本地提交历史会发生变化。此时普通git push通常会失败需要使用gitpush --force-with-lease这里仍然不建议直接使用git push -f。因为--force-with-lease会先检查远程分支是否有别人新的提交如果远程已经被别人更新它会拒绝覆盖相对更安全。需要注意的是这种清理操作更适合自己的功能分支尤其是在提交合并请求之前。如果这个分支已经有其他人共同开发或者别人已经基于你的提交继续开发就不要随意 rebase 和强推否则容易造成大家的提交历史不一致。简单来说git commit --amend更适合修正最近一次提交git rebase -i更适合在合并前整理一段提交历史。它们的目标都是让最终进入主分支的提交更加清晰而不是把开发过程中的每一次临时修正都原样保留下来。amend、reset、revert 的区别git commit --amend、git reset和git revert都和提交历史有关但它们解决的问题不同。amend是修改最近一次提交本质是创建一个新的 commit 来替换旧 commitreset是移动当前分支指针可以把分支退回到某个提交revert是新增一个反向提交用来撤销某个历史提交带来的修改。比如gitcommit--amend-mnew message适合修正最近一次提交。gitreset--softHEAD~1会撤销最近一次 commit但保留暂存区内容。gitreset--hardHEAD~1会撤销最近一次 commit并且丢弃工作区修改这个命令风险比较高执行前一定要确认。gitrevert a1b2c3d不会重写历史而是新增一个 commit 来反向撤销a1b2c3d这个提交。对于已经推送到远程、多人协作的分支来说revert通常比reset或 amend 更安全。已经 push 后为什么要谨慎使用 amend如果 commit 还没有 push 到远程使用 amend 一般只影响本地历史风险相对较小。但是如果这个 commit 已经推送到了远程再执行 amend本地和远程的提交历史就会不一致。原来本地和远程都是A --- B本地执行 amend 后变成A --- B而远程仍然是A --- B这时候普通的git push通常会失败因为 Git 会发现远程和本地历史不一致。如果确实需要推送 amend 后的历史一般需要使用gitpush --force-with-lease不建议直接使用gitpush-f因为-f会强制覆盖远程分支而--force-with-lease会先检查远程分支是否被别人更新过。如果远程已经有了别人的新提交它会拒绝覆盖相对更安全。所以在团队开发中如果某个 commit 已经被别人拉取或者已经推送到公共分支比如main、develop、release就要谨慎使用 amend。因为 amend 本质上是历史重写一旦别人已经基于旧 commit 开发就可能导致双方历史不一致。amend 后旧 commit 去哪里了执行 amend 后旧 commit 并不是立刻从仓库里消失只是当前分支不再指向它。比如原来是A --- B ^ mainamend 后变成A --- B ^ main旧的 B 变成了暂时没有分支引用的 commit。如果想找回可以通过git reflog查看 HEAD 的移动记录gitreflog可能会看到类似结果e4f5g6h HEAD{0}: commit (amend): init amend demo a1b2c3d HEAD{1}: commit: init demo如果确实要回到旧提交可以使用gitreset--harda1b2c3d不过git reset --hard会丢弃当前工作区修改执行前一定要确认是否还有未保存的代码。实际开发建议实际开发中如果只是本地刚提交完发现 message 写错了、文件漏提了或者代码需要补一个小修改可以直接使用git commit --amend。这种场景下 amend 能让提交历史更干净避免出现很多“fix again”“update”“补文件”之类没有独立意义的 commit。提交后也可以先检查一下当前状态和提交内容gitstatusgitlog--onelinegitshow--stat确认文件是否完整、提交说明是否准确、有没有把不该提交的配置文件带进去。如果发现问题在 push 之前用 amend 修正是比较自然的做法。如果要修改的不是最近一次提交而是倒数第二次或者更早的提交就使用gitrebase-iHEAD~n只修改提交说明用reword需要修改代码用edit。如果 commit 已经推送到远程尤其是多人协作分支就要谨慎处理必要时优先和团队确认再考虑是否使用git push --force-with-lease。常用命令整理修改最近一次提交说明gitcommit--amend-m新的提交说明补充遗漏文件并保留提交说明gitaddxxx.javagitcommit--amend--no-edit修改最近一次提交内容和说明gitadd.gitcommit--amend查看当前 commit 对象gitcat-file-pHEAD查看 HEAD 移动记录gitreflog修改倒数第二个 commitgitrebase-iHEAD~2amend 后推送远程gitpush --force-with-lease最后总结git commit --amend表面上看是修改最近一次提交但从 Git 内部机制来看它并不是原地修改旧 commit而是创建一个新的 commit然后让当前分支指向这个新的 commit。也正因为如此amend 后 commit id 会发生变化。可以简单理解为amend修改最近一次 commit本质是重写当前 commit rebase -i修改历史中的某一次或多次 commit reset移动分支指针 revert新增一个反向提交不重写历史在本地开发阶段amend 是一个非常实用的工具可以用来修正提交说明、补充遗漏文件、合并小修改让提交历史保持清晰。但如果 commit 已经推送到远程尤其是公共分支就要谨慎使用因为它会改写历史。理解这一点之后再看git commit --amend它就不只是一个修改提交信息的命令而是理解 Git commit、HEAD、branch、parent 之间关系的一个很好入口。