1

在 git flow 分支模型（如本文所述）中指出，应该release通过分支来创建分支develop。

这可以很好地工作，但据我所知，也可能导致意外更改使其进入release分支。假设您正在处理特征 A、B 和 C，并将它们合并到develop. 几天后，功能 A 和 B 变得足够稳定，可以发布，但功能 C 仍然落后。您不希望功能 A 和 B 因为功能 C 而被延迟，并且您不能恢复功能 C，develop因为其他开发人员依赖它。

作为对此的解决方案，我认为将功能 A 和 C 分支release出来master然后合并到它上面。

（我仍然不是 100% 熟悉 git，所以我下面的一些陈述可能完全错误，所以请澄清一下。）

这样做的问题是，因为特性 A 和 B 与特性 C 一起开发，并且开发人员保持他们的特性分支与develop分支保持同步，所以 C 的一些代码最终出现在特性分支 A 和 B 中。如果我合并这些分支到release分支然后我可能会在那里得到来自 C 的代码。我仍然习惯于变基的想法，但是如果我尝试使用变基而不是合并，我会遇到所有这些冲突。也许我可以挑选提交或类似的东西，但是每次我想在发布分支上放一些代码时，这似乎太复杂了。

你们能否让我知道是否有一种简单的方法可以实现这一目标？

4

2 回答 2

5

我想你误解了你提到的帖子。它说，“已完成的功能可能会合并到开发分支中......”。

您通常不会将不稳定的功能合并到develop分支中。

于 2013-07-02T18:16:24.050 回答
2

正如 gtrig 所说，在准备好之前，应避免将功能 C 合并到开发中。

我们认为origin/develop是 HEAD 源代码始终反映下一个版本的最新交付开发更改状态的主要分支。有人将其称为“集成分支”。这是构建任何自动夜间构建的地方。

一旦完成，有不同的方法可以解决这个问题，但是分支 master 是错误的方法。如果您从 master 分支，那么您将不会获得任何新功能，或者您将挑选提交或以其他方式创建新的、未经测试的软件版本。您应该分支开发，因为这是测试新功能的分支（或者至少应该测试它们）。

如果 C 语言的问题不需要大量工作，那么可以在发布分支上修复它们以及发布测试中发现的其他错误。

如果 C 的问题确实需要大量工作，那么应该在创建发布分支之前在开发分支上恢复 C。主要工作可能发生在 C 的特性分支上，当 C 最终准备好合并到开发时，这会导致一些痛苦，或者发生在新特性分支上，这会导致历史有点误导，但否则会起作用.

如果其他开发人员在为开发分支做好准备之前依赖 C，那么他们应该直接使用 C 的特性分支，或者直接使用他们自己的子分支。

于 2013-07-02T18:56:47.527 回答