我仍然试图从git转向git-flow。我知道我可以在git-flow中使用任何类型的git功能，但我最感兴趣的是它自动处理的内容。
假设有两位开发人员Alice和Bob，分别处理功能A和B.当Alice完成后，她可以执行git flow feature finish A基于提交C在她的本地develop分支上创建合并提交。现在如果Bob同时完成了他的功能，并且他获取了相同的东西，他的合并提交也将基于C.现在，如果Alice推送然后再次取消，他将必须合并或变基，我们最终得到develop分支上的非线性历史记录，以防他汇合。
到目前为止这是正确的，还是git-flow以某种方式自动处理这种情况？如果有一些自动机制，必须为此设置什么才能工作？
最简单的解决方案可能是在完成功能之前始终获取develop。但是我不确定这实际上是否可行，具体取决于共享存储库的方式（当时可能不可用）。
编辑（问题的澄清）：
正如答案所示，我的例子并不清楚。首先，我想到的问题是：
C是开发分支的初始提交。
Alice在功能分支上创建了一些功能：
develop feature/A
| |
v v
C-A1-A2-A3-A4
同时Bob也为另一个功能
工作C-A1-A2-A3-A4
\
B1-B2-B3-B4
现在，Alice完成了该功能，并添加了合并提交以进行开发（我希望如此）。
A1-A2-A3-A4
/ \
C- - - - MA
现在Bob完成了这个功能，并再次添加了一个合并提交来开发（我也想要，只是在另一个地方：
A1-A2-A3-A4
/ \
C- - - - MA <- develop for Alice
\
\ - - - - MB <-develop for Bob
\ /
B1-B2-B3-B4
然而，现在Alice或Bob必须合并develop，创建一个额外的提交：
A1-A2-A3-A4
/ \
C- - - - MA-MAB <- I don't want this MAB commit
\ /
\ - - - - MB <-develop for Bob
\ /
B1-B2-B3-B4
我想要的是这样的：
A1-A2-A3-A4
/ \
C- - - - MA-MB
\ /
B1-B2-B3-B4- -
正如您所看到的，历史记录仍然是非线性的，但是开发分支的主线只包含来自功能的合并提交（并且没有其他情况下的其他合并提交）。
我喜欢这个，就是你可以轻松地跟踪历史记录中的变化，看看它们是否属于以前的特征分支，或者它们是否在开发中合并。所有这些信息都可以直接从DAG中获得。
此外，如果您在开发时使用好的消息进行合并提交，则在第二种情况下，您可以通过始终跟随开发的第一个父项来轻松派生更改日志。但是在第二种情况下，您有时需要仅跟随第一个父级，有时需要跟随多个父级。我无法看到何时可以编写代码的简单方法。
答案 0 :(得分：3)
git-flow没有这样做。
它旨在支持the branching model described here（这对于Git开发人员推荐的各种事物来说真的很漂亮）。 该图片包含合并。您将在整个文本中看到相同内容。在每种类型的分支下，您将看到它们应该合并的分支类型。有一些示例命令，使用--no-ff强制避免线性历史记录，而是记录合并提交。
这是一个真正使用Git的工作流程，Git的核心优势之一是分支和合并。这个工作流程在合并时蓬勃发展;非线性历史不仅是不可避免的，而是期望的。
您应该阅读工作流程说明中标题为“将完成的功能纳入开发”的部分。简短的引用：
--no-ff标志使合并始终创建新的提交对象，即使可以使用快进执行合并。这样可以避免丢失有关功能分支历史存在的信息，并将所有一起添加功能的提交组合在一起。
...
不幸的是，我还没有找到办法让--no-ff成为git merge的默认行为，但它确实应该是。
你想要那些合并提交。你真的这么做。
答案 1 :(得分：0)
Jefromi说，MAB在历史上合并没有任何害处。
有一种方法可以避免这种提交，通过将其功能合并推送到中央仓库的方式（假设这是B），不合并其他合并提交（这里MA ）进入自己的历史。相反，第二个必须销毁本地合并提交（MB），并重做合并，其中第一个父级现在不是C，而是第一个父级的合并提交（MA }）。所以第二个开发人员现在创建一个合并，其中包含另一个合并和自己的分支（新的MB）。
就我个人而言，我不关心MAB提交，但是不想解释为git新手提供MAB免费历史记录所需的所有步骤。