3

我仍在尝试从 git 转向 git-flow。我知道我可以在 git-flow 中使用任何类型的 git 功能，但我最感兴趣的是它自动处理的内容。

假设有两个开发人员 Alice 和 Bob，分别在功能 A 和 B 上工作。当 Alice 完成后，她可以根据提交 Cgit flow feature finish A在她的本地分支上创建一个合并提交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 完成了这个功能，并再次添加了一个合并提交来开发（我也想要那个，只是在另一个地方：

  A1-A2-A3-A4
 /           \
C-  -  -  -   MA <- develop for Alice
 \
  \ -  -  -   - MB <-develop for Bob
   \           /
    B1-B2-B3-B4

然而现在 Alice 或 Bob 必须合并开发，创建一个额外的提交：

  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 中获得。

此外，如果您在开发中为合并提交使用好的消息，在第二种情况下，您可以通过始终关注开发中的第一个父级轻松导出更改日志。但是，在第二种情况下，您有时只需要关注第一个父母，有时需要关注多个父母。而且我看不到什么时候可以编写代码的简单方法。

4

2 回答 2

3

git-flow没有那样做。

它旨在支持此处描述的分支模型（这实际上只是 Git 开发人员推荐的各种事物的美丽图景）。该图片包括合并。你会在整个文本中看到相同的内容。在每种类型的分支下，您会看到它们应该合并到的分支类型。有示例命令，--no-ff用于强制避免线性历史记录，而是记录合并提交。

这是一个真正使用 Git 的工作流，而 Git 的核心优势之一就是分支和合并。这个工作流程在合并上蓬勃发展；非线性历史不仅是不可避免的，而且是可取的。

您应该阅读工作流程描述中标题为“在开发中合并已完成的功能”的部分。一个简短的报价：

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

...

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

你想要那些合并提交。你真的会。

于 2012-01-10T17:57:17.587 回答
0

MABJefromi 是正确的，在历史上进行合并并没有什么坏处。

有一种方法可以避免这种提交，顺便说一下，将他的功能合并推送到中央仓库的那个（假设是 B）不会将另一个合并提交（此处MA）合并到自己的历史记录中。相反，第二个必须销毁本地合并提交（MB），并重做合并，现在第一个父级不是C，而是第一个（MA）的合并提交。因此，第二个开发人员现在创建了一个合并，其中包含另一个合并和自己的分支（新的MB）。

就我个人而言，我不关心MAB提交，但不想向MAB刚接触 git 的人解释获取免费历史所需的所有步骤。

于 2012-01-11T12:02:26.630 回答