ProGit书籍中的箭头方向

为什么在所有显示pro git book箭头提交队列的图像上都会导致相反的方向？ProGit书籍中的箭头方向

2010-04-20 Denis Palnitsky

这是显示父母的关系。在Git中，特定的提交知道它的父项，但不一定关于它的子项。（显然，这些信息可以根据家长的联系中得到，但我不认为这是直接存储在commit对象。）

2010-04-20 15:20:32 mipadi

Correct - 提交对象的内容是提交的元数据（作者，提交者，消息），树（目录树的内部表示）以及父提交的SHA1。也就是说，一个承诺通过SHA1“指向”其父母（而不是其子女），正如箭头所示。 – Cascabel 2010-04-20 15:24:29

这个箭让我发狂。仍然理解为什么这些信息对于所有图像都是必需的。 – 2010-04-20 15:36:40

这些箭头很有用，因为您可以通过图表中的箭头告诉很多关于历史的信息。例如，查看提交C3，C4和C5。从箭头中可以看出，C3和C4共享一个以C2开始的共同历史记录（即它们每个都从C2分支出来），C5向我们显示它是C3和C4合并的结果，这意味着它包含C3和C4的变化，以及这两个提交的共同历史。 – mipadi 2010-04-20 15:48:15

箭头体现在这里代表提交的在历史的方向，接着一个DAG, Directed Acyclic Graph Git（从最近到最早）。

这表示是不是一个“完美”的一个，为Eric Sink details in his article：

一个关于基于DAG的版本控制工具的最酷的事情是，DAG是合并历史的表达。我们将DAG中的箭头解释为“我有这个”。

alt text

所以，当谈到时间做从5B在合并到（一）分支，我们可以使用DAG中的信息，要知道，3B和2b已经完成

同一篇文章详细介绍了代表性的限制：

Cherrypicking

但DAG只是一种实现，合并的历史，它肯定是不完美的。

版本控制中的箭头DAG从子项到父项。它告诉我们该孩子包含父母中的所有更改。和它的祖父母。和它的曾祖父母。等等。

但是，如果这不是事实呢？

请看下面的图片：

alt text

我想创建变更4.
我想在变更1开始，然后我想申请从3变更的变化，但不是变更集2中的东西。
此操作有时称为“挑剔”。我不想将所有更改从一个分支合并到另一个分支。我只想采用一个变更集（或变更集的一部分）并将其作为补丁应用于其他某个地方。

我该如何在DAG中表示这一点？

我不行。

我可以画一个箭头从4到3（红色如上所示）。这可以正确地说4包含3中的变化，但它会不当地声称4包含变化2.
或者，我可以不绘制箭头。实际上，我的合并历史会简单地不记录的事实，4是真的3转换成一个补丁，并应用于1

在这两种情况下，坏事要发生下一次，我从一个分支合并其他：

如果我绘制躺在箭，我不会给应用变更2的机会，因为合并历史认为我已经做到了。

如果我不绘制任何箭头，该工具将指望我处理变更集3，因为没有合并历史记录我已经完成的事实。

这些问题都不足以造成晚间新闻灾难，但仍然如此。

这就是为什么a rebase is never far经过樱桃挑选操作后，为了找回更经典的DAG。

来源

2010-04-20 15:59:21 VonC

ProGit书籍中的箭头方向

回答

相关问题