我们想切换到Git，但是什么让我们退缩是一个工作流程。我们使用perforce。我们有几个团队共享相同的代码库。我们目前有两个分支，Stage和Release。我们每天由changset合并从舞台到发行。我们永远不会准备将所有阶段合并到发布。这非常有效，因为我们可以合并一个开发人员的变更或整个团队。如果存在冲突，它的所有自动化和开发人员都会参与进来。
我考虑与Git合并，这对分支机构非常有效，但在changset级别却不行。
将我们的工作流程移至Git的最佳方法是什么，而不放弃我们现在要合并我们想要的任何变更集的灵活性？
答案 0 :(得分：3)
cherry-pick是一个可用于合并任意变更集的命令。
您还可以在使用新工具时重新考虑工作流程。例如在git中分支是快速且便宜的，您可以选择一个描述here的基本策略或者找出自己的策略。而且你不需要任何合并工具，它只是工作。
答案 1 :(得分：2)
您可以在git中通过changeset合并;它被称为樱桃采摘。没有冲突，可以在没有开发人员干预的情况下进行挑选。您也可以定期修改发布分支，以使它们之间的实际分歧更清晰。
答案 2 :(得分：1)
有三种技术可以帮助你。
首先，在Release上，您可以cherry-pick只需要您想要的更改集（提交）。
其次，如果Stage的某些（前缀）分数是可合并的，则可以仅合并到您想要的最新提交，而使其余的分支不合并。对您而言，这可能不太可能。
最后，您可以为每个新功能创建小分支，而不是直接向Stage添加更改集。将此类分支合并到Stage以进行测试以及所有其他功能;然后，当接受该功能时，将原始的小功能分支合并为主要功能。
我强烈推荐第三种方法。它为您提供了最大程度的控制，并且仍然与您习以为常的工作流程保持一致。
答案 3 :(得分：1)
您可以使用cherry-pick Git命令合并分支。它可以用于合并提交范围。
示例命令cherry-pick A..B和cherry-pick --stdin。阅读Git create branch from range of previous commits?
答案 4 :(得分：1)
虽然其他人已经正确地指向了git cherry-pick，但您应该理解＆＃34;变更集＆＃34;可能具有您最初可能拥有的更广泛的含义。
问题是，大多数人，据说包括你，意味着＆＃34;变革集＆＃34;与＆＃34;提交＆＃34;相同。但是，考虑开发人员实现的功能可能会更有成效，并且这些功能可以上演，测试，可能经过改进，然后传播到生产就绪的开发线。
一旦考虑了功能而不是变更集，您的分支和合并方法可能会变得不那么严格。
您可能让每个开发人员/团队为每个功能或他们正在处理的错误修复都有一个单独的分支。也就是说，不要在一个临时分支上开发所有东西。然后，当功能/错误修复准备就绪时，该分支将合并到一个测试分支（它可能是您的单个＆＃34;阶段＆＃34;分支或单独的分支），可以使用修复程序快速修复返回到他们修改的更改的分支，然后 分支可能被视为＆＃34;准备好＆＃34;再次合并 - 这次进入＆＃34;制作＆＃34;分支。
另一种方法是制定一项政策，即不要只有一个＆＃34;特征＆＃34;在＆＃34;测试＆＃34;分支，然后当测试完成时，测试分支本身可能会合并到生产分支中（Git可以重复合并）。
您可以考虑阅读＆＃34;存储库，分支机构和文档＆＃34; this document中的一节详细介绍了如何维护Git本身的开发，this one被认为是Git工作流程的首选指南＆＃34;很多人请不要将这些指南视为教条 - 它们可以向您展示人们在生产中成功使用的方法。相比之下，github uses a radically different approach也很有趣。