在 Git 上并行处理大量更改可能会非常痛苦。你会不断地 juggle 分支和提交，并运行可怕的 rebase -i 命令，如果你不小心打个喷嚏，就可能会让你的树处于半损坏的状态。jj，作为 Git 的一个替代品，如今被广泛讨论（1、2、3、4），而且常常被作为解决方案。虽然我非常认同 jj 尝试解决的问题，但它解决问题的方式并没有让我完全信服。在过去的 1.5 年中，我每三个月尝试使用 jj 几天，真心希望它能成为我的工作流程的一部分，但最终我还是放弃了，回到了 Git[1]。这就是 Git 历史命令的用武之地。它是一个实验性命令，在两个版本中推出，分别是 2.54（四月，重命名和拆分子命令）和 2.55（六月，修复子命令）。每次版本发布日都吸引了一阵关注，但据我所知，之后社区讨论并不多。这很可惜，因为在我看来，它已经提供了很多人所宣传的 jj 的好处，而无需完全切换工作流程。令人惊喜的是，它是 Git 核心发行版的一部分，因此你可以试用而无需安装任何东西。它有三个子命令：fixup、reword 和 split。fixup git history fixup 修复了一个有问题的旧提交，然后自动为所有分支进行 rebase，以使其匹配。你可以像往常一样使用 git add 来暂存修复，然后运行 git history fixup <commit> 将这些暂存的更改合并到目标提交中。这就像是 git commit --fixup 加上一个自动 squashing rebase，但额外的神奇在于，它还会更新所有包含该提交的其他分支。最后这一部分超出了 git rebase --update-refs，因为后者仅移动在你正在主动 rebase 的范围内的引用。Git 历史则会查找并重写每个从该提交派生的本地分支（同时也提供了一个选项，仅限于当前分支）。另一方面，它在存在合并提交时无法工作，这对于某些 Git 的用法可能会是一个问题。下面是它在实践中的工作原理：之前，B 提交已暂存的修复：在执行 git history fixup B 后：B* 是将修复合并进 B。重写一个提交会给它一个新的哈希值，因此 C 和 D 会自动在上面重建为 C* 和 D*，而 feat-1 和 feat-2 分支的尖端也会随之移动。所有三个命令的最重要特性是它是原子的：它从不让你的树处于半损坏状态。它通过拒绝任何可能产生冲突的操作来管理这一点。明确来说，这相较于 jj 的功能会弱一些。jj 将冲突视为一类优先的操作，因此它可以在 rebase 过程中保持冲突的状态，并让你稍后处理。Git 历史尚未做到这一点，但文档为此留了余地：“这个限制是有意为之，因为历史重写并不打算是有状态的操作。一旦 Git 学会了有关一类优先冲突的内容，这个限制可以解除。”所以基本上，这个限制可能在将来会改变；期待看看是否会发生变化！reword git history reword 更新旧提交的提交信息并自动为其上面的所有内容进行 rebase。这对于在迭代过程中设计发生变化时，回去修复提交信息非常有用。git history reword <commit> 会打开你编辑器中的该提交的现有信息。你进行编辑、保存，其余的堆栈会在上面被重建，相关分支也会跟随。这与 fixup 很类似，但更改的是提交信息而不是树的内容。因为它只更改信息，reword（如稍后的 split）根本不接触你的索引或工作树；它纯粹作用于提交图。因此，两者都可以让你在未 checkout 的分支上重写提交，而不妨碍你正在进行的工作。之前：在 git history reword B 后：只有 B 的信息发生了变化，但这仍然会使它拥有一个新的哈希值，因此 C 在上面重建为 C*，而 feat-1 也随之更新。split git history split 会将一个提交拆分为两个，以交互方式选择你关心的每一部分。这相当于 git add -p，但不需要与 git rebase 进行复杂操作。我发现这是三者中最专业的，但在需要时非常宝贵。具体而言，git history split <commit> 会让你进入一个逐块提示，查看该提交的 diff。你保留的每一块构成第一个提交，其余的则落入第二个提交。之前，B 同时捆绑了两个无关的修改：在 git history split B 后：B 变成了 B1 和 B2，而 C 在这对组合的上方重建为 C*。结论 根据有多少人使用 jj，我确实认为还有一些我尚未做到的关键思维转变。要明确的是，Git 历史并未填补所有的空白：jj 仍然为你提供一个操作日志，并带有轻松撤销的功能，将你的工作副本建模为提交，并可以在 rebase 中保留冲突，而这些 Git 历史并未尝试实现。但现在，Git 历史是在采用许多吸引人们使用 jj 的元素方面迈出了重要一步。