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