我正在尝试将Git flow介绍给我的团队。我们是一个相当小的团队,而且相当敏捷。我们希望每天发布一次,这意味着我们在一天中测试所有更改的时间有限。业务团队希望能够控制即将发布的功能,尽管这并不理想。
Git flow似乎不能很好地适应这一点。在从开发中删除一个发布分支之后,将选定的特性合并到master的最佳方式是什么。选择樱桃是唯一的选择吗?有没有更好的方法?
发布于 2012-12-17 01:15:56
如果业务团队想要控制下一个版本中有哪些功能,那么标准的git flow处理并不理想。但其他分支机制也会遇到同样的问题。
git flow的默认结构是为每个新特性创建一个特性分支。一旦您完成了新特性的构建(和测试),您可以将该分支合并回您的develop分支中,然后删除feature分支。然后,该功能将包含在下一个版本中。
如果一个特性不应该包含在下一个版本中,那么您不应该将feature分支合并回develop分支。这是确保它不会被包括在内的最好方法。它还可以防止其他开发人员创建使用(或以其他方式需要)新功能的代码。
我不建议你挑三拣四。首先,一个特性可以(并且经常会)有多个提交,并且很容易忘记一个。其次,如果特性B使用在特性A中添加的代码,并且管理层想要释放特性B而不释放特性A,您很可能会发现特性B被破坏了。而且这些依赖关系并不总是很容易被发现。
管理层想要确定新特性的优先级是有道理的,但每个特性都应该在完成(和测试)后立即合并回开发分支中。
发布于 2012-12-15 07:11:14
如果每个特征都有自己的分支,只需合并该特征分支即可。
https://stackoverflow.com/questions/13887454
复制相似问题