Git合并指定的提交

Question

经典的TFVC分支;每个开发签到都进入DEV分支。当开发人员想要将他的更改发送到TEST环境时，他将他的更改合并到TEST分支。当他想将此更改发送到生产时，他将他的更改合并到PROD分支。他在TFS GUI中手动选择这些更改。这种方法适用于“如果我不合并我的更改，我相信它不会被部署到相应的环境”这一事实。

但是，在Git合并中，没有选择合并哪些提交的选项。因此，当开发人员将其功能提交合并到开发分支时，这些提交可以很容易地通过未来另一个开发人员的合并发送到主分支。

在Git中，我如何创建分支策略以便我可以选择要合并的提交？

Answer 1

Git支持Cherry Pick merges。此方法允许您选择单个更改并将它们合并到另一个分支中。另一个选择是interactive rebase of the desired changes onto another branch。此机制允许您将更改从一个分支（最好是不与整个团队共享的功能或主题分支）重播到另一个分支。

然而，促销级别分支模式有点过时，并不适合Git的分布式特性（在分布式版本控制世界中，哪个环境合并了代码，在世界的哪个地方） 。您可能想要查看许多其他模式。能够进行二进制升级（使用相同的字节在DEV，TEST和PROD上运行），容器化（甚至主机infra沿着该路径移动），Infra作为Code和Config as Code，允许您轻松地旋转环境，不必通过一组固定的环境依赖于管道;这种和git能够比TFVC更容易隔离较小的功能分支，旧的促销级别分支模型不再达到标准。对不起; /

微软最近记录了Release Flow，这是一个轻量级的模型，它确实隔离了候选版本，并随着分支的成熟而随后修复。

GitHub还发布了他们的分支/合并流程流程的文档。他们称之为GitHub Flow。

你可能也会找到很多GitFlow的参考资料，它非常受欢迎，并且与促销级别策略相匹配。然而，由于该模型中许多分支的长期存在及其相对复杂性，许多人正在慢慢背弃它。

这些其他型号的原因与此模型启用的更容易的高频交付有关，并且您在一个环境中测试的内容与您发布的相同信心更高到另一个。持续集成和自动化测试等实践可以帮助确保现有代码的质量，同时进行更改和其他实践（如临时功能标记）将允许您发布尚未完成的工作，同时确保其保持关闭状态。因此，这些新实践不是试图完全隔离来自单个开发人员的特定半集成更改，而是尝试更频繁，更快地增加开发人员之间的集成，从而允许您更快地移动较小的更改。隔离是通过稍微延迟合并或者根本不延迟并通过其他机制实现隔离来实现的。

Answer 2

只是为@ jessehouwing的优秀回复添加一些评论。

有许多宗教信仰和采摘樱桃不是git方式＆＃34;那里的言论。毫无疑问，git合并在git中运行得更好，事实上它在任何修订控制系统中都会更容易，因为文件冲突问题可以通过无序的挑选更容易产生。但仅仅因为某些东西更容易，或者因为它适用于某些开源工作流程，并不意味着它是唯一的方式，甚至它本身就更好。

挑选樱桃的路线肯定更加困难，而且无论出于何种原因，您必须确保您的流程需要额外的复杂性。否则它绝对不值得。但如果你这样做......

不幸的是，在微软的文章中没有讨论过挑选樱桃的最大麻烦，那就是你更容易遇到冲突。一些更改会修改相同的代码行，并尝试将它们无序移植...冲突。如果你是一个大型组织，你可能会遇到这个很多。我现在给你的建议是：

1. 您无法允许手动解决冲突。这是因为一旦您有一个手动冲突解决方案，源和目标分支就不同了，您刚刚复杂化了未来的冲突问题。相反，你需要的是确保任何阻止＆＃39;提交首先被挑选到目的地分支。 （*）
2. 您将需要制作工具来自动尝试挑选所有可能的提交，识别潜在的阻止提交并确保链中的所有阻塞提交都已准备就绪＃34; （无论你的过程决定了什么）。 （负责这项工作的人很快就会不堪重负。）

这是一个非常简要的概述樱桃采摘工作流程面临的一些问题，但如果你把它作为指南，你就可以自己快速地发现细节。

（*）根据您的工作流程，这可能无法实现。例如，如果尚未准备好采摘樱桃，因为它尚未获得监管部门的批准。但如果它只是＆＃34;测试人员尚未对其进行测试＆＃34;，则需要鼓励测试人员尽快测试它。