我正在尝试向我的团队介绍Git流程。我们是一个相当小的团队，非常敏捷。我们希望每天发布一次，这意味着我们有限的时间来测试当天的所有变化。业务团队希望能够控制即将发布的功能，尽管它并不理想。
Git流似乎不能很好地适应这一点。切割发布分支后，开发什么是合并所选功能的最佳方法。樱桃采摘是唯一的选择吗？还有更好的方法吗？
答案 0 :(得分：10)
如果业务团队想要控制下一版本中的哪些功能，则标准git flow处理并不理想。但是你会遇到与其他分支机制相同的问题。
git flow的默认结构是为每个新功能创建功能分支。完成构建（并测试）新功能后，将分支合并回开发分支，然后删除功能分支。然后该功能将包含在下一个版本中。
如果某个功能不应包含在下一个版本中，则不应将功能分支合并回开发分支。这是确保不包括在内的最佳方法。它还可以防止其他开发人员创建使用（或以其他方式要求）新功能的代码。
我不建议采摘樱桃。首先，一个功能可以（并且经常会）有多个提交，很容易忘记一个。其次，如果功能B使用在功能A中添加的代码，并且管理员希望在不释放功能A的情况下发布功能B，则可能会发现功能B已损坏。这些依赖关系并不总是很容易被发现。
管理层希望确定新功能的优先级是有道理的，但每个功能应在完成（并经过测试）后立即合并回开发分支。
答案 1 :(得分：0)
如果每个要素都有自己的分支，只需合并该要素分支。