我对在大型项目设置中使用 git 不是很有经验，但我刚刚完成了这个令人惊叹的可视化教程。我不明白的一件事是，在一个练习中，它要求您对先前提交的代码进行小幅更改（更改图像的尺寸）。为此，它让您重新排序提交，以便添加具有旧维度的代码的提交位于顶部，修改该提交，然后将所有内容重新排序回原来的方式。
结果是您没有额外的小提交来修复图像的尺寸，而是您有一堆所有变基或挑选的垃圾工件。
与简单地添加新提交相比，本教程中介绍的技术有什么优势？或者，如果在这种特定情况下它是矫枉过正，但在其他一些情况下有一个很好的理由，那么什么是一个例子，为什么在它的上下文中它不是矫枉过正？在我看来，这只是教条，但由于我如此缺乏经验，我确信我错了。
经验法则：如果我们想要更改的提交先前已推送到共享存储库，请不要修改/重新设置/重写历史记录。只需在分支顶部再次提交，然后推送它。
因此，假设C1您必须更改的提交 () 仅在本地分支上。C1添加图片和链接到图片的一些更改。
如果您C2在顶部进行另一个提交（仅更改图片），如果您稍后想要挑选由 带来的功能的内容，则C1必须同时挑选C1（初始图片和其他更改）和C2（更新的图像）。
尽管如此，在大多数日常情况下，您只需进行另一次提交。在对开源项目提出拉取请求之前，这种“功能分支制作”可能很有用，因为它使您的提交干净且原子，因此更容易审查。
一个原因是为了让提交历史更容易理解。
这类似于考虑不是为计算机编写程序，而是为另一个人编写程序（有更多评论，更少评论甚至没有评论的论点 - 但每个人都同意清晰是好的）。这就像一篇带有红笔更正的论文草稿和一个新的草稿之间的区别，重写后没有所有令人分心的错误开始和错误。
在您提交新功能、提交其他几个功能、然后对之前的功能（错误修复/错别字/等）进行小幅更改的场景中，保持历史实际发生的方式可能更容易让您理解，因为您记得做那个修复（或者可能形成一个叙述，如果你第一次看到初始版本，变化会更有意义；这取决于它是否更清晰）——但对于其他人来说，它通常是不必要的复杂。对他们来说，让它看起来好像该功能一开始就完成了会更简单。
最后，他们重新排序、修改然后再次重新排序的具体方法对我来说似乎不必要地复杂。我只是交互式地变基（git rebase -i parent_of_commit_to_be_changed），标记该提交以进行修改（通过将“pick”更改为“edit”或“e”），编辑文件，等等按照 git 给你的说明。
（注意：这仅用于在推送之前准备您自己的私有存储库- 正如@GuillaumeDarmont 所说，在推送后修改历史记录会给已经获取/拉取它的任何人带来麻烦。）