编辑任意提交

错别字在三周前的一个提交里。常规的修法是交互式变基：停在那个提交上，编辑，继续， 然后祈祷。Gitcito 的修法是：右键点击提交，编辑此提交，改好文字，完成。提交 详情面板里的钢笔按钮打开的也是同一个编辑器。

它做什么

选中任意一个属于 HEAD 祖先的提交 — 历史是否线性都无所谓。模态框会显示它的文件 和提交信息，两者都可以编辑。接下来会发生两件事：

1. 预览级联会把被编辑提交之上的每一个提交在内存中重放一遍（一串 merge-tree 拣选 — 没有检出，没有工作区，没有 ref）。每个后代提交都会显示为 绿色或红色，所以在任何东西真正移动之前，你就知道这次编辑是干净地传播下去， 还是会与后来的改动相撞。
2. 改写历史才是动真格的：同一条链用底层命令构建出来，然后分支用 reset --keep 移动过去 — 你未提交的改动会被一并带上，否则重置中止，什么都没有 发生。执行前会先拍一份守护快照，撤销则会恢复原来的提交链。

每个被重放提交的作者信息和日期都保持不变；变的只有哈希 — 这正是改写历史的含义。

范围内的合并

提交与 HEAD 之间存在合并提交时，编辑不再被禁用。级联重放合并的方式，是把它的 记录结果 — 该合并当初实际提交的那棵树，连同冲突的解决方案一起 — 重新应用到改 写后的父提交上，因此当年手工做出的解决方案会原封不动地在改写中幸存下来。没有 rerere，没有重新合并，没有工作区：与级联其余部分相同的内存内底层命令，而且两个父 指针都会保留。同样包含被编辑提交的旁支分支会被改写并重新指向；不包含它的分支则身 份不受任何触碰。模态框中的横幅会说明范围内带有多少个合并，预览中的合并步骤会显示 一个合并图标。

诚实的告诫：重放的合并只能和它记录的结果一样好。如果你的编辑与该合并自己解决过的 那些行相撞，预览会像任何其他冲突步骤一样变红 — 不做任何猜测。

级联发生冲突时

某个后来的提交改动了你正在编辑的那些行。预览会把该提交连同冲突文件一起标为红色， 改写会拒绝执行 — 绝不会出现只应用了一半的情况。要么换一种改法，要么用 交互式变基正面解决冲突。

限制

• 提交必须是 HEAD 的祖先。 未合并的旁支分支上的提交没有通往当前分支的路 径可供重放。
• 二进制文件和超过 2 MB 的文件会显示但不可编辑。
• 已经推送到远程的提交也可以编辑，但你的下一次推送将不得不是强制推送 — 模态框 会在你做出这个决定之前发出警告。
• 提交中被删除的文件无法编辑（没有内容可编辑）。

另请参阅： 交互式变基 · 恢复与 reflog · 吸收