如何在Git中编辑和修改旧提交记录的最佳实践

Question

我对在大型项目设置中使用git不是很有经验，但我刚刚学习了这个惊人的视觉教程。其中一个问题是在一个练习中，它要求您对来自以前提交的代码进行小修改（更改图像的尺寸）。为此，它要求您重新排序提交，使添加旧尺寸代码的提交位于顶部，修改该提交，然后将所有内容重新排序回原来的方式。 结果是，您没有多余的小提交修复图像的尺寸，而是有一堆重新基于和挑选的垃圾工件。 教程中介绍的技术与仅添加新提交相比的优势是什么？或者也许在这种特定情况下它是过度设计，但在某些其他情况下有充分理由，那么可以举个例子，并解释为什么它在其上下文中不算过度设计吗？据我看来，这只是教条主义，但由于我经验不足，所以我肯定是错的。

- adrusi

Answer 1

如果我们想要更改的提交已经被推到共享仓库中，请不要修改/变基/重写历史记录。只需在分支顶部做另一个提交，然后将其推送。

---

假设你需要更改的提交 (C1) 只存在于本地分支上。 C1 添加了一张图片和与图片相关的一些更改。

如果你在其之上再做一个提交 C2（仅更改图片），如果以后你想要挑选由C1带来的功能内容，那么你必须挑选C1（最初的图片和其他更改）和C2（更新的图片）。

但是，在大多数日常情况下，您只需要做另一个提交即可。这种“特性分支构建”在为开源项目做拉取请求之前非常有用，因为它可以使您的提交干净而原子化，从而更容易审核。

- Guillaume Darmont

---

值得解释一下为什么更改已经推送到存储库中的提交是如此糟糕 - 如果您有自己的[特性]分支，并且没有其他人与您共享，我怀疑不会有任何问题。 - om-nom-nom

不错的答案！更像是时间上的内聚而非空间上的（遗憾的是，“时间上的内聚”已经被使用了）。 - 13ren

Answer 2

一个原因是要使提交历史更易于理解。 这类似于考虑编写程序不是为了计算机，而是为了另一个人（有关注更多评论、少些评论甚至没有评论的争论 - 但每个人都认为清晰度是好的）。 这就像把一篇文章的草稿与红笔校正全部弃掉，重新用新的草稿重写一样。 在你提交新功能、提交其他几个功能，然后对以前的某个功能进行小更改（修复错误/拼写错误等）的情况下，保持历史记录的方式实际发生可能更容易让你理解，因为你记得做了那个修复（或者可能形成一个叙事，如果您首先看到初始版本，则更改会更有意义；这取决于是否更清晰） - 但对于刚看到它的其他人来说，通常是不必要复杂的。对他们来说，最简单的方法是似乎一开始就完成了该功能。 最后，他们重新排序、修改，然后再次重新排序的具体方法对我来说似乎过于复杂了。我只会交互式地变基（git rebase -i parent_of_commit_to_be_changed），标记要修改的提交（通过将“pick”更改为“edit”或“e”），编辑文件，并按照git给出的指示进行操作。 （注意：这仅适用于在推送之前准备自己的私有存储库 - 正如 @GuillaumeDarmont所说，在推送之后修改历史记录会给已经获取/拉取它的任何人带来麻烦。）

- 13ren