git-flow是否强制某些分支保持线性历史记录

Question

我正在努力从git向git-flow转移。我知道我可以在git-flow中使用任何类型的git功能，但我主要感兴趣的是它自动处理的部分。

假设有两个开发者Alice和Bob，分别在功能A和B上工作。当Alice完成时，她可以使用 git flow feature finish A 在基于提交C的本地develop分支上创建合并提交。现在，如果Bob在同一时间完成他的特性，并且他获取了相同的东西，则他的合并提交也将基于C。现在，如果Alice推送然后Bob再次获取，他将不得不合并或重新组织，我们最终会在 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完成了该功能，并再次将合并提交添加到develop分支（我也希望如此，只是在另一个位置）：

  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中推导出来。

此外，如果您在开发分支上使用良好的合并提交消息，在第二种情况下，您可以通过始终遵循开发分支上的第一个父级轻松推导出更改日志。但是，在第二种情况下，有时需要仅遵循第一个父级，有时需要遵循不止一个父级。我无法看到何时进行编码的简单方法。

- LiKao

---

非线性历史有什么问题吗？合并具有重要意义；例如，它们标记了您将错误修复合并到稳定分支中，这是您尝试使用的工作流程的固有部分。如果您强制自己使用非线性历史，则会失去这一点。 - Cascabel

@Jefrom：我想我没有能够准确地解释我的意思。我更新了问题以澄清我不感兴趣的是完全线性的历史，而是在分支合并的情况下尝试保留第一/第二个父级的含义。 - LiKao

好的，无论如何，“git-flow”仍然不会做任何这方面的事情。我可以编辑我的答案以删除它不执行的原因，但是...该答案确实回答了你的问题。 - Cascabel

Answer 1

git-flow并不是那样的工具。

它旨在支持这里描述的分支模型（实际上只是Git开发人员建议的一些漂亮图片）。该图片包括合并操作。你将在整个文本中看到相同的内容。在每种类型的分支下，您将看到应该将其合并到的分支类型。有示例命令，使用--no-ff来强制避免线性历史记录，并记录合并提交。

这是一个真正使用Git的工作流程，而Git的核心优势之一就是分支和合并。这个工作流程依赖于合并；非线性历史记录不仅是不可避免的，而且是期望的。

您应该阅读“将已完成的功能合并到develop”章节的工作流程描述。以下是一个简短的摘录：

--no-ff标志始终会创建一个新的提交对象，即使可以使用快进方式进行合并。这样可以避免丢失关于功能分支的历史存在的信息，并将所有一起添加该功能的提交组合在一起。

...

不幸的是，我还没有找到一种使--no-ff成为git merge默认行为的方法，但它真的应该是这样。

您需要这些合并提交。确实如此。

- Cascabel

---

好的，我想我的例子可能不太清楚。我并不是想要保持完全平坦的历史记录，而仅仅是简化一些分支。我会尝试更新问题以澄清我的意思。 - LiKao

@LiKao：我理解你的例子，但我仍然认为非线性历史并不是坏事。无论如何，git-flow不会自动修改您的历史记录。它只包装了一些简单的操作 - 大多数是分支创建和解决。 - Cascabel

我能看到 MA 和 MB 提交的重要性，我都想要。然而，我无法看到 MAB 提交所增加的任何信息价值，我正试图摆脱它（刚刚尝试了一下，发现实际上并不容易）。您能更明确地说明MAB提交提供的附加信息吗？ - LiKao

@LiKao：这个可能不会提供太多信息。显然其他的更有意义。但我仍然不介意拥有它——它表示劳动分工，有时您关心需要跟踪哪位开发者谈论特定的更改。如果您想用rebase来消除它，那就去做吧。不过您必须手动完成！ - Cascabel

@Cascabel 我注意到日期了。只是我没有看到其他人声称（就像链接的文章中那样），Git项目在2010年做过这件事。 - Guildenstern

Answer 2

Jefromi说得对，将MAB合并到历史记录中不会有任何影响。

其实有一种方法可以避免这个提交。假设第一个开发者（我们称之为B）将他的特性合并到中央仓库时，不要将另一个合并提交（这里是MA）合并到自己的历史记录中。相反，第二个开发者必须销毁本地合并提交(MB)，然后重新进行合并，其中第一个父提交现在不是C，而是第一个开发者的合并提交(MA)。因此，第二个开发者现在创建了一个包含另一个合并和自己分支（新的MB）的合并。

个人认为我不会在意MAB提交，但不想向新手解释获取无MAB历史所需的所有步骤。

- Rudi