问题描述
在使用CI/CD循环时，遇到了一些问题，希望能找到一个更好的模型。主要问题出现在Gitflow方面。他们目前的模型是：有两个Bitbucket分支：master和develop。这两个分支通过Webhooks与Jenkins关联，以便部署到生产和开发服务器。QA团队在开发服务器上测试功能和发布。开发团队负责前端和后端开发，遇到了很多问题。问题是：团队经理希望能够更好地控制接受/拒绝的功能。比如：developer1将一个功能提交到develop分支，developer2在develop上添加了一个热修复，我们希望QA团队能够轻松地分别测试它们，然后尽可能少地麻烦地一起测试。然后轻松选择哪个提交保留并移动到master分支。正如我所说，这主要是一个Gitflow的问题。有什么建议吗？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
这个问题的关键是如何选择性地应用提交，这是非常棘手的。基本上，你如何知道提交是依赖还是独立的？
正如你正确提到的，这是Gitflow本身的一个问题，所以解决方案是转变方法论。目前首选的方法是基于主干的开发（Trunk-Based Development，TBD）- 参考 “Accelerate” 一书中的证据：https://trunkbaseddevelopment.com/。
在TBD中，你可以选择一种工作方式，即使用短期的功能分支。一旦一个功能完成，就创建一个拉取请求，并在这样的短期分支下选择性地进行QA测试，然后批准合并到主分支。
这样，你就知道你的分支是独立的（不像Gitflow中的提交），并且可以选择性地批准功能。请注意，在Gitflow中也可以通过多个不同的分支实现类似的效果，但在那里会变得非常混乱。
方案2
TBD方法可能需要一些团队的适应和改变，但它可以提供更好的控制和灵活性。你可以尝试在小规模项目中实施TBD，以便团队逐渐适应并评估其效果。
另一种方法是使用Gitflow的一些变种来解决你的问题。你可以创建多个不同的分支，以便QA团队可以选择性地测试功能。例如，你可以为每个功能创建一个短期分支，然后在这些分支上进行QA测试。一旦QA测试通过，你可以将这些分支合并到develop分支，并在合并之前进行必要的冲突解决。然后，你可以将develop分支合并到master分支。
这种方法可能会导致分支的数量增加，但可以提供更好的控制和选择性。然而，需要注意的是，这种方法可能会增加分支管理的复杂性，并且需要确保分支之间的依赖关系正确设置。
无论你选择哪种方法，都需要与团队成员进行充分的沟通和协作，以确保他们理解并适应新的工作流程。