Gitflow和Accidently Merging其他功能

Question

我们最近开始介绍gitflow，主要介绍一些youtube视频和一些在线文章 - 以及SourceTree中的GUI功能。

然而，我们认为我们正在做错事，因为我们正在遇到我们希望解决的情况。

developer 1正在处理feature 1，developer 2正在处理feature 2，develop分支用于开发和正在进行，{{1}分支是实时/生产

开发者1

1. develop = master（与master同步）
2. 开发 - ＆gt;分支到功能-1
3. 开发＆lt; - 在feature-1中合并

开发人员2

1. develop！= master（与主人同步）
2. 开发 - ＆gt;分支功能-2
3. 开发＆lt; - merge feature-2

现在我们遇到问题，如果master希望通过将developer 2合并到feature 2来实现master - 它将包含feature 1，这意味着他们都会去住。

所以我们显然做错了 - 这就是我们需要澄清的内容，我能看到的唯一两种方式就是

• 您可以从master而不是develop
创建新功能
• 您使用“Cherry Pick”只会将实际更改的文件转换为master

我们想要的解决方案是混合使用没有发布周期的Web开发项目，一旦客户注销了该功能，它们就会生效，因此非常感谢有关如何实现这一目标的建议。

由于

Answer 1

好吧，根据gitflow文档http://nvie.com/posts/a-successful-git-branching-model/：

  

已完成的功能可以合并到develop分支中，以便将它们添加到即将发布的版本中

因此，dev 1不应将feature 1合并到develop，直到下一版本100％保证。如果是这种情况，那么dev 2分支就没有问题，包括feature 1。如果feature 1位于develop，则应将其视为“已完成”，但错误修正除外，它不能轻易从develop中移除。

那就是说，我觉得gitflow很麻烦，我自己更喜欢http://dymitruk.com/blog/2012/02/05/branch-per-feature/。除了在结构上更清洁之外，它具有巨大的好处，在任何时候都可以轻松地从“下一个版本”中退出功能，并且您所面临的“问题”（一个特征隐含地带来另一个特征）不会发生

Answer 2

当开发人员1将功能1重新合并到开发中时，它应该已经准备就绪。

因此，将特征2和特征1重新定位应该没有问题。

但你有几个选择。

1. 尚未完成功能1（如果尚未准备就绪，请不要将其合并回develop）。
2. 更频繁地发布（首先发布功能1，一旦完成）。
3. 使用功能切换（具有属性feature1.enabled=false）并释放功能1以及功能2，但功能已禁用。

请记住，在git flow下，版本总是来自develop分支，因此理想情况下，您可以随时使用生产就绪代码从develop发布版本。