为什么使用git rebase -i重新排序提交不会搞砸历史？

Question

据我所知，提交文件的快照所以如果我执行更改A然后更改B，更改B的提交文件已包含更改A中的更改，不会重新排序更改A冗余吗？

Answer 1

也就是说，其实是一个非常好的问题，因为提交是快照。

底垫原因的工作原理是因为底垫实际上是重复git cherry-pick（有位在前面包裹的找出该选择什么样的，多在年底移动分支标签），并git cherry-pick作品转动承诺变更集。

假设，例如，你有提交的序列：

  A--B--C <-- topic 
     /
...--o--*--o--o  <-- mainline 

变基topic到mainline我们需要（1）发现，上topic的提交，但不mainline（这是C，B ，并沿着第一行A，结束于标记为*的提交），然后（2）将它们复制到新的提交中，我们将在mainline的提示下添加新提交。

再次基于第一发现三个后*提交，并将它们放入一个（反向下令：A，B，C）列表（也忽略了合并默认的提交，但这里没有合并）。然后它为每个提交做一个樱桃选择。

为了挑选A，Git比较A而不是*。这将两个快照转换为变更集。混帐然后应用最尖端提交的mainline的更改，使一个新的承诺，让我们称之为A'，在一个匿名的分支：

  A--B--C <-- topic 
     /
...--o--*--o--o  <-- mainline 
       \ 
       A' <-- HEAD 

要樱桃采摘B，Git的diff文件B对A。将这些更改应用于A'会产生另一个提交B'。重复C获得C'：

  A--B--C   <-- topic 
     /
...--o--*--o--o   <-- mainline 
       \ 
       A'-B'-C' <-- HEAD 

最后，从Git的剥离C的topic标签路程，它指向C'代替。链老被放弃（虽然你仍然可以通过reflogs找到它，rebase副本C的ID，以特殊的名字ORIG_HEAD以及）：

  A--B--C   [abandoned] 
     /
...--o--*--o--o   <-- mainline 
       \ 
       A'-B'-C' <-- topic 

现在的重订完成。

请注意，如果需要，每个副本都使用git的合并机制完成（如果diffs不适用于干净地）。每个人都可能导致合并冲突，需要重组停止并获得您的帮助。 （或者，更糟糕的是，你可能会错误合并，尽管这些在实践中很少见。）

当然，如果您重新订购提交（通过在交互式转化中移动pick行），我们只需更改我们选择的顺序并应用每个提交。樱桃采摘操作仍然以相同的方式工作：比较挑选的提交与其父母（C与B,A与*,B与A）。