git - 线性历史在版本控制中意味着什么？

Question

我很少听说过在 Git 或 Mercurial 中保持线性历史。这实际上意味着什么？谁能给我提供一个简单的例子？

Answer 1

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

如果您的代码在源代码管理下具有线性历史，这意味着代码中的每个提交更改都是在前一个代码之后进行的。将其视为一个长的单一代码更改链，如下所示:

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

* 表示HEAD。

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

但是，Git 允许您分支 代码，因此您可以同时处理多个版本的代码。假设这是您的提交历史到目前为止的样子:

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

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

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

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

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

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

现在，他们在做什么并不重要，因为在您的分支机构中，您拥有您自己的代码副本，您可以随心所欲地使用它。因此，您在分支 [F] 和 [G] 上进行了两次提交:

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

测试更改后，您认为 merge 回 master 已经足够好了:

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

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