Question

很少有人听说过在Git或Mercurial中保留线性历史记录。它究竟意味着什么？有人可以给我提供简单的例子吗？

Answer 1

TL; DR - 在线性源控件中，每个更改必须在另一个之后进行。在非线性源控制中，可以在任何点同时进行代码更改并合并到主线中。

如果源代码管理下的代码具有线性历史记录，则意味着代码中的每个提交的更改都是在前一个代码之后进行的。可以把它想象成一个长长的单链代码更改，如下所示：

[A]---->[B]---->[C]---->[D]
                         *

*表示HEAD。

使用这种方法，您必须始终处理最新的代码，因此，如果您处于提交[B]并且您当前正在处理最终将提交的更改[D]，那么您需要从存储库中提取以从[C]获取更改，以便在没有冲突的情况下推送您的代码。

但是，Git允许您branch您的代码，因此您可以同时处理多个版本的代码。让我们说这是你的提交历史到目前为止的样子：

[A]---->[B]
         *

现在假设您想要进行一些更改，但您不想打扰[B]。（也许其他人正在同时处理这段代码，谁知道？）在Git中，你可以从你提交的branch来处理你自己的当前代码版本。这是Git的基石：多人可以处理同一个文件而不会覆盖彼此的更改。与源代码控制相比，这是一个巨大的优势，具有严格的线性历史，代码冲突更加令人讨厌。

无论如何，回到这个例子。您创建了一个新分支，而其他人继续将更改推送到原始master分支。

[A]---->[B]
           \
            [E]
             *

假设您在自己的分支上进行了两次提交[C]和[D]：

[A]---->[B]---->[C]---->[D]
           \
            [E]
             *

现在，它们正在做什么并不重要，因为在您的分支中，您拥有您自己的代码副本，并且您可以随意使用它做任何事情。因此，您在分支上进行了两次提交，[F]和[G]：

[A]---->[B]---->[C]---->[D]
           \                   
            [E]---->[F]---->[G]
                             *

在测试了您的更改后，您认为将其合并回master：

就足够了

                                 *
[A]---->[B]---->[C]---->[D]---->[H]
           \                   /
            [E]---->[F]---->[G]

这基本上是非线性源控制的工作原理。你可以看到很多人很容易在不踩脚趾的情况下处理相同的代码。现在，如果两个人正在处理同一个文件，仍然会出现合并冲突，但是Git有一个名为git-merge的漂亮工具，它有助于在同一个文件中合并两个人的并发更改。

线性历史在修订控制中意味着什么？

1 个答案: