在Integration-Manager工作流中，提交树的外观如何？

Question

https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows

  

这种方法的一个主要优点是你可以继续   工作，主存储库的维护者可以拉你的   任何时候都有变化。贡献者不必等待该项目   结合他们的变化 - 每一方都可以按照自己的节奏工作。

我做了一张照片，展示了我认为它会如何运作，这是正确的吗？

Answer 1

您的图表确实显示了可能的工作流程。然而，更常见的是，维护人员首先将开发人员的工作合并到maintainer，然后在步骤4合并开发人员的工作，反之亦然，创建两个单独的工作合并看起来更像：

o     o
|  o  |
| /|  |
|/ |  |
o  |  o
|  |  |
o  |  o
|  |  |
o  |  o
 \ | /
  \|/
   o

接下来是：

   o
   |\
   | \
o  |  o
|  o  |
| /|  |
|/ |  |
o  |  o
|  |  |
o  |  o
|  |  |
o  |  o
 \ | /
  \|/
   o

在第4步。或者，如果维护者是Git大师的东西，他们可以使用所谓的章鱼合并来保持中间＆＃34;维护者＆＃34; path作为主线，因此只有一个合并，但它看起来像这样：

o     o
|  o  |
| /|\ |
|/ | \|
o  |  o
|  |  |
o  |  o
|  |  |
o  |  o
 \ | /
  \|/
   o

中间列提交的第一个父级是图形中最底部的提交。