在经典的 TFVC 分支中；每个开发签入都进入 DEV 分支。并且当开发人员想要将他的更改发送到 TEST 环境时，他会将他的更改合并到 TEST 分支。当他想将此更改发送到生产环境时，他会将更改合并到 PROD 分支。他在 TFS GUI 中手动选择了这些更改。这种方法有利于“如果我不合并我的更改，我确定它不会部署到相应的环境”。
但是，在 Git 合并中，没有选项可以选择要合并的提交。因此，当开发人员将他的功能提交合并到开发分支时，这些提交可以很容易地通过另一个开发人员的未来合并发送到主分支。
在 Git 中，如何创建分支策略以便我可以选择要合并的提交？
【问题讨论】：
标签： git tfs branch branching-and-merging tfvc
Git 支持Cherry Pick merges。此方法将允许您选择单个更改并将它们合并到另一个分支中。另一种选择是发送interactive rebase of the desired changes onto another branch。这种机制将允许您将更改从一个分支（最好是不与整个团队共享的功能或主题分支）重播到另一个分支。
然而，升级级别的分支模式有点过时，并且不太适合 Git 的分布式特性（在分布式版本控制世界中，在哪个环境中，谁合并了代码，在世界的哪个地方）。您可能想研究许多其他模式。能够进行二进制提升（使用相同的字节在 DEV、TEST 和 PROD 上运行）、容器化（甚至主机基础设施也沿着该路径移动）、基础设施即代码和配置即代码，让您可以轻松地启动环境，不必单独依赖通过一组固定环境的管道；这和 git 比 TFVC 更容易隔离较小功能分支的能力，旧的提升级别分支模型不再符合标准。对不起;/
Microsoft 最近记录了 Release Flow，这是一个轻量级模型，它确实隔离了候选发布版本，并随着分支的成熟挑选后续修复。
GitHub 还围绕其分支/合并流程发布了文档。他们称之为GitHub Flow。
您可能还会找到很多关于 GitFlow 的参考资料，它非常流行并且更符合促销级别的策略。然而，由于该模型中许多分支的寿命长且相对复杂，许多人正在慢慢放弃它。
这些其他模型的原因与此模型更容易实现更高频率的交付有关，并且您在一个环境中测试的内容与您发布到另一个环境的内容相同的信心更高。持续集成和自动化测试等实践可以帮助确保现有代码的质量，同时进行更改，而临时功能标志等其他实践将允许您发布尚未完成的工作，同时确保它保持关闭状态。因此，这些新实践并没有尝试将特定的半集成更改与单个开发人员完全隔离，而是尝试更频繁、更快地增加开发人员之间的集成，从而使您能够更快地移动较小的更改。隔离要么通过稍微延迟合并来实现，要么完全不延迟并通过其他机制实现隔离。
【讨论】：
只是想为@jessehouwing 的出色回复添加一些 cmets。
那里有很多宗教“摘樱桃不是 git 方式”的言论。毫无疑问，git 合并在 git 中效果更好，事实上，在任何版本控制系统中它都会更容易，因为文件冲突问题可能更容易出现乱序的樱桃选择。但仅仅因为某些东西更容易，或者因为它适用于某些开源工作流，并不意味着它是唯一的方法，甚至它本身就更好。
挑选路线肯定更困难，而且您必须确保您的流程，无论出于何种原因，都需要额外的复杂性。否则绝对不值得。但如果你这样做......
不幸的是，微软文章中没有讨论樱桃采摘的最大问题，那就是您更有可能遇到冲突。一些更改修改了同一行代码，并且您尝试将它们无序移植......冲突。如果您是一个大型组织，您可能会遇到很多很多。在这一点上我给你的建议是这样的：
这是对挑选工作流程所面临的一些问题的非常简短的概述，但如果您将其作为指南，您将自己很快发现细节。
(*) 根据您的工作流程，这可能是不可能的。例如，如果某件事还没有准备好挑选，因为它还没有获得监管部门的批准。但如果只是“测试人员尚未测试”，则需要鼓励测试人员尽快进行测试。
【讨论】：