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