我仍然试图从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
免费历史记录所需的所有步骤。