我正在尝试向我的团队介绍 Git 流程。我们是一个相当小的团队，而且非常敏捷。我们希望每天发布一次，这意味着我们只有有限的时间来测试当天的所有更改。业务团队希望能够控制正在发布的功能，尽管这并不理想。
Git 流程似乎不能很好地适应这一点。从 develop 中删除发布分支后，将选定功能 merge 到 master 的最佳方法是什么。 cherry-pick 是唯一的选择吗？有没有更好的办法？
最佳答案
如果业务团队想要控制下一个版本中的哪些功能，则标准的 git flow 处理方式并不理想。但是你会遇到与其他分支机制相同的问题。
git flow 的默认结构是为每个新功能创建一个功能分支。完成构建(和测试)新功能后，将分支 merge 回开发分支，然后删除功能分支。然后该功能将包含在下一个版本中。
如果一个特性不应该包含在下一个版本中，你不应该将特性分支 merge 回开发分支。这是确保它不会被包括在内的最好方法。它还会阻止其他开发人员创建使用(或以其他方式需要)新功能的代码。
我不建议 cherry-pick 。首先，一个特性可以(而且经常会)有多次提交，而且很容易忘记一次。其次，如果功能 B 使用添加到功能 A 中的代码，而管理层想要发布功能 B 而不发布功能 A，您可能会发现功能 B 已损坏。而且这些依赖关系并不总是很容易发现。
管理层希望优先考虑新功能是有道理的，但每个功能都应该在完成(和测试)后尽快 merge 回开发分支。
关于git flow 发布选定的功能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13887454/