在git flow分支模型中（如this post中所述）指出应该通过release分支创建develop分支。
这可以很好地工作，但据我所知，也可能导致意外更改，使其进入release分支。假设您正在处理功能A，B和C，并将它们合并到develop。几天后，功能A和B变得足够稳定以便释放，但功能C仍然落后。您不希望功能A和B因功能C而延迟，并且您无法从develop恢复功能C，因为其他开发人员依赖它。
作为解决方案，我认为将release分开master，然后将功能A和C合并到其上。
（我仍然不是100％熟悉git，所以下面的一些陈述可能完全错误，所以请澄清。）
问题在于，因为功能A和B与功能C一起开发，并且开发人员使用develop分支使其功能分支保持最新，所以C的一些代码最终出现在功能分支A中和B.如果我将这些分支合并到release分支，那么我可能最终得到C中的代码。我仍然习惯于变基的想法，但如果我尝试使用rebase而不是合并，我会得到所有这些冲突。也许我可以选择提交或类似的东西，但每次我想在发布分支上放置一些代码时，这似乎太复杂了。
如果有一种简单的方法可以让我知道吗？
答案 0 :(得分：5)
我认为你误解了你提到的post。它说，“完成的功能可能会合并到开发分支......”。
您通常不会将不稳定的要素合并到develop分支。
答案 1 :(得分：2)
正如gtrig所说，应该避免将功能C合并到开发中，直到它准备就绪。
我们认为
origin/develop是主要分支，其中HEAD的源代码始终反映下一版本中最新已交付开发更改的状态。有些人称之为“整合分支”。这是建立任何自动夜间构建的地方。
一旦完成，有不同的方法可以解决这个问题，但分离主人是错误的方法。如果您从master分支出来，那么您将获得任何新功能，或者您将会选择提交或以其他方式创建新的未经测试的软件版本。您应该分支开发，因为它是测试新功能的分支（或者至少它们应该已经过测试）。
如果C的问题不需要大量工作，那么可以在发布分支上修复它们以及发布测试中发现的其他错误。
如果C的问题确实需要主要工作，那么在创建发布分支之前，应该在开发分支上恢复C。主要的工作可能发生在C＆C的功能分支上，当C最终准备合并到开发中时会产生一些痛苦，或者在新的功能分支上会发生，这会导致历史记录有点误导，否则会起作用。
如果其他开发人员在为开发分支做好准备之前依赖C，那么他们应该直接使用C的功能分支，或直接使用他们自己的子分支。