我们有一个CI过程，我们将开发分支中的更改推送到dev服务器和QA服务器进行测试。一旦我们对变更工作感到满意并且QA已通过测试，我们希望樱桃选择来自该品牌的更改并将其合并到主分支中，以推送到我们的暂存和发布环境。目前，在TFS的构建/发布过程中，发布到开发和质量保证是自动化的。是否有一个任务和/或变量，我们可以添加，当我们推动分期时，我们可以樱桃选择更改并合并到主分支并将主分支移动到暂存环境？现在，这将是一个手动过程，容易出现人为错误，并且会破坏我们的CI过程，从而依赖于人工干预。我们正在使用当前的TFS系统。Cherry Pick在TFS中自动发布
谢谢。
此合并过程很容易出错。从你的过程看起来也是如此，它是一个不同的代码库或包，它在从开发到qa或升级时被测试。
我建议你看看基于主干的构建。如果您正在开发新功能并且不属于下一个计划版本，则应该在功能分支中完成。或者一旦中继线已经过测试并通过集成，用户接受，性能或安全测试，那么您可以从中继线分支出来并创建候选分支分支。发布候选分支的任何更改都需要合并到主干。在这一点上，不要指望有很多变化。这个想法是尽可能晚地分支出去。
基于主干的构建并不新鲜。它已经被大小公司所采用，并且接受了敏捷和devops实践。
注意：正在开发特定功能的开发人员应创建自己的功能分支。一旦稳定，它们就可以合并到主干。然后可以删除特征分支。
简短的回答是，没有办法自动做你要问的东西。如果你想这样做，你必须编写自己的代码才能这样做。我强烈建议不要这样做，原因如下：
你正在做的是持续集成的对立面。从代码库挑选正确集成的工作特征并将它们合并到另一个分支将更好地称为连续隔离。
通过利用已在集成状态进行了测试对一个开发和QA环境，并移动到一个新的分支和重建的变化，你实际上完全无效做了所有以前的测试。
更好的方法是使用功能切换（又名功能标志）来禁用仍在开发中的功能，并将应用程序以禁用不完整功能的集成状态发送。