所以管理层在 Git 上出售。我们目前使用 Perforce 并将变更列表从阶段合并到发布分支，当它们准备好时。我们当前工作流程的优势是我们可以选择哪些功能用于生产，而不必担心发布周期。一经测试，一切顺利。
使用 Git，我们的工作流程将是开发人员在 dev 分支或他们自己的分支中工作。然后，他们将更改合并到阶段（测试）分支以供 QA 测试。
一旦 QA 完成测试，PM 将希望将这些更改合并到发布分支并部署到生产。诀窍是我们可能在 Stage 分支中测试了 10 个东西，只有一个准备好合并到 Release。
我知道合并整个 Stage 分支来发布很容易，但这永远不会发生。同样使用 Git 樱桃选择是可怕的，如果我们不能按分支合并，那么使用 Git 没有多大意义。在perforce 中，我们将changlelists 从stage 合并到Release。
我们如何在 Git 中做到这一点？
能给我举个例子吗？
您可以在合并到 stage 分支时保留 dev 分支，并在您希望将其用于生产时立即合并该 dev 分支。请记住，这会导致阶段分支成为“转储”分支。仅在该分支中进行的更改将永远不会进入生产环境。因此，需要在相关的开发分支中进行修复，如果发生具有两个功能的集成问题（合并冲突或逻辑冲突），您可能需要另一个合并这些开发分支的分支。在后一种情况下，这些更改只能一起合并到生产中（使用具有冲突解决方案的分支。）
也就是说，请记住，您的阶段分支不会包含非常有效的测试状态。可能有些功能以某种方式与其他功能相关，因此将其中一个与另一个合并是行不通的。由于合并错误，您可能会认识到这一点 - 但也可能会发生您不认识它的情况。
因此，测试彼此隔离的功能可能是一个更好的主意（例如，在其开发分支中的每个功能都没有来自其他分支的更改）。这可能需要额外的努力，因为您需要为此完成单独的测试，包括环境。但是，它将帮助您以将其合并到生产中的方式测试功能。另一方面，一旦您将任何内容合并到生产环境中，这将需要再次测试其他功能 - 测试基础可能已经发生了重大变化。
只要您没有定义一个指定的功能列表，然后将其合并到生产环境中并且可以在这种组合中进行测试，那么我可以想象没有完美的技术解决方案。要么一起测试所有未来的特性——在这种情况下，干扰可能会在测试时发生，并且一旦特性被合并就会丢失。或者您对单独的功能进行测试，并需要在每次合并到生产后重新测试它们，以确保这两个功能没有负面冲突。
根据您的团队的工作方式，可能会相信开发人员能够牢记可能的干扰。但是，它迟早会发生，这不起作用并且由于工作流程而发生错误。