git-flow是否在某些分支上强制执行线性历史记录

时间:2012-01-10 17:00:32

标签: git git-flow

我仍然试图从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中获得。

此外,如果您在开发时使用好的消息进行合并提交,则在第二种情况下,您可以通过始终跟随开发的第一个父项来轻松派生更改日志。但是在第二种情况下,您有时需要仅跟随第一个父级,有时需要跟随多个父级。我无法看到何时可以编写代码的简单方法。

2 个答案:

答案 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免费历史记录所需的所有步骤。