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

Question

很多次我听说过在Git或Mercurial中保留线性历史记录。这实际上意味着什么？有人能给我提供一个简单的例子吗？

Answer 1

TL; DR - 在直线状的源控制，每改变必须在其他之后进行。在非线性源代码控制中，可以在任何点同时进行代码更改并合并到主线。

如果源代码控制你的代码有一个线性的历史，这意味着在代码中的每个提交的更改是一前一后制成。把它看成是代码变化长，单链，这样的：

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

的*表示HEAD。

使用这种方法，您必须始终使用最新的代码，所以如果您使用的是[B]，并且您正在进行最终将提交[D]的更改，则需要从存储库中提取从[C]获取更改以便无冲突地推送您的代码。

但是，GIT中让你branch你的代码，这样你就可以在代码的多个版本一次。比方说，这是怎么了你的提交历史至今：

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

现在假设你想做出一些改变，但你不想打扰[B]。 （也许其他人正在同时处理这些代码，谁知道呢？）在Git中，您可以使用branch来处理您自己的当前代码版本。这是混帐的基石：多的人可以在同一个文件上工作，而不会覆盖彼此的更改。与严格线性历史的源代码控制相比，这是一个巨大的优势，代码碰撞更麻烦。

不管怎样，回到例子。您创建一个新的分支，而其他人继续将更改推送到原始的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极好的工具，有利于合并在同一个文件中的两个人的并发修改。