Integration-Manager Workflow 中的提交树是什么样子的？

Question

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

One of the main advantages of this approach is that you can continue to work, and the maintainer of the main repository can pull in your changes at any time. Contributors don’t have to wait for the project to incorporate their changes — each party can work at their own pace.

我制作了一张图片，展示了我认为它的工作原理，正确吗？

Answer 1

您的图表确实显示了一个可能的工作流程。然而，更典型的做法是，维护者首先将开发人员 A 的工作合并到 maintainer，然后合并开发人员 B 的工作，反之亦然，在第 4 步，创建两个独立的合并，看起来更像：

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

其次是：

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

在第 4 步。或者，如果维护者是某种 Git 大师，他们可以使用所谓的 octopus merge 来保持中间 "maintainer"路径为主线，这样就只有一个merge但是看起来是这样的：

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

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

Integration-Manager Workflow 中的提交树是什么样子的？

How commit tree would look like in Integration-Manager Workflow?

git

integration

workflow