Git Flow发布选择的特性。

Question

Git Flow发布选择的特性。

18

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

Git flow 似乎不能很好地满足这一需求。从 develop 分支创建一个 release 分支后，最佳的方式是将所选功能合并到主分支(master)的唯一选择是通过 cherry-pick 吗？是否有更好的方法？

- dark_src

我们目前都是一条船上的人，正在尝试这个想法：与其合并，我们将从主分支（主分支始终是最新的稳定部署版本）中分叉出一个 releaseXYZ 分支，并使用 squash merge 将各个特性分支挑选到发布中。然而，我们还需要在 dev 环境中测试所有内容，而我们只有一个环境可以进行部署，因此我们还需要不断地将所有特性分支 squash merge 到 dev 中，以便 dev 可以扮演一个“全包含”的实验场所。目前计划如上，因为 squash 不会创建一个合并提交，所以源分支仍然保持干净。 - seekingtheoptimal

2个回答

0

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

- aragaer

这个回答怎么帮助解决用户提出的关于能否选择实际发布哪些功能的问题呢？ - pal4life

git checkout master; git merge feature1 feature2 feature3 feature4 - 这不就是需要的吗？通过合并这些分支来选择要发布哪些功能。如果一个功能没有合并到主分支，那么就不会发布该功能。 - aragaer

那么您的建议是将计划发布的功能合并到主分支中，而将不需要发布的功能仅留在功能分支中？ - pal4life

基本上是这样的。对于每个你想要包含在发布中的功能，将功能分支合并到发布分支中。然后将发布分支合并到开发分支中。重新定位所有其他功能以便它们位于当前开发的顶部也可能很方便 - 现在你有了从最新发布点增长的“新”功能分支，如果你不需要它们，你可以删除“旧”的功能分支。 - aragaer

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Arjan · Accepted Answer

标准的git flow处理方式并不理想，如果业务团队想要控制哪些功能在下一次发布中，但使用其他分支机制也会遇到同样的问题。

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

如果一个特性不应该包含在下一个发布版本中，您就不应该将该特性分支合并回develop分支。这是确保它不会被包含在内的最佳方法。它还可以防止其他开发人员创建使用（或以其他方式需要）新特性的代码。

我不建议使用cherry-pick。首先，一个特性可能会有多个提交，很容易忘记其中一个。其次，如果特性B使用了在特性A中添加的代码，并且管理人员希望发布特性B而不发布特性A，您可能会发现特性B出现故障。这些依赖关系并不总是易于发现。

管理层希望优先考虑新功能是有道理的，但每个特性应该在完成（和测试）后尽快合并回develop分支。