git flow 发布选定的功能答案

【问题标题】：git flow releasing selected featuresgit flow 发布选定的功能
【发布时间】：2012-12-14 23:03:22
【问题描述】：

我正在尝试向我的团队介绍 Git 流程。我们是一个相当小的团队，而且非常敏捷。我们希望每天发布一次，这意味着我们只有有限的时间来测试当天的所有更改。业务团队希望能够控制即将发布的功能，尽管这并不理想。

Git 流程似乎不能很好地适应这一点。从开发中删除发布分支后，将所选功能合并到主控的最佳方式是什么。樱桃采摘是唯一的选择吗？有没有更好的办法？

【问题讨论】：

我们目前处于同一条船上，并且正在试验这个想法，而不是合并，我们将从 master 分叉一个 releaseXYZ 分支（master 是始终部署到 prod 的最新稳定版本)，并使用 squash 合并将单个功能分支选择到版本中。不过，我们还需要在 dev 中测试所有内容，而且我们只有一个可以部署的 envi，因此在 dev 中我们还不断压缩合并所有功能分支，因此 dev 可以充当“全能”的实验游乐场。到目前为止，这是计划，因为 squash 不会创建合并提交，所以源分支保持干净

【解决方案1】：

如果业务团队想要控制下一个版本中的功能，标准的git flow 处理并不理想。但是其他分支机制也会有同样的问题。

git flow 的默认结构是您为每个新功能创建一个功能分支。一旦你完成了新特性的构建（和测试），你将分支合并回你的开发分支，然后删除特性分支。然后该功能将包含在下一个版本中。

如果下一个版本中不应包含某个功能，则不应将该功能分支合并回开发分支。这是确保它不会被包括在内的最佳方法。它还阻止其他开发人员创建使用（或需要）新功能的代码。

我不建议挑选樱桃。首先，一个特性可以（并且经常会）有多个提交，并且很容易忘记一个。其次，如果功能 B 使用了在功能 A 中添加的代码，并且管理层希望在不发布功能 A 的情况下发布功能 B，那么您很可能会发现功能 B 已损坏。而且这些依赖项并不总是很容易发现。

管理层希望优先考虑新功能是有道理的，但每个功能都应该在完成（和测试）后立即合并回开发分支。

【讨论】：

> 但是其他分支机制也会有同样的问题。诚然，这不是源代码管理应该管理的事情。 Release Toggles (aka Feature Flags) 更适合这个目的

【解决方案2】：

如果每个功能都有自己的分支，只需合并该功能分支。

【讨论】：

hmm，这个答案如何帮助解决用户提到的关于能够选择实际发布的功能的问题？
git checkout master; git merge feature1 feature2 feature3 feature4 - 这不是我们需要的吗？您可以通过合并这些分支来选择要发布的功能。您不会发布未合并到主分支的功能。
所以你的建议只是将计划发布的功能合并到 master 中，而将不发布的功能只留在功能分支中？
基本上是的。对于要包含在发布中的每个功能，将功能分支合并到发布分支中。然后将发布分支合并到开发分支。将所有其他功能重新定位到当前开发之上也可能很方便 - 现在您拥有从最新发布点开始增长的“新”功能分支，如果您不需要它们，您可以删除“旧”功能分支。跨度>