结合测试/ QA流程的Git分支策略
我们的开发团队一直在使用GitFlow分支策略，这非常棒！ 最近，我们招募了一些测试人员来提高我们的软件质量。这个想法是每个功能都应该由测试人员进行测试/质量检查。 过去，开发人员在单独的要素分支上处理要素，并develop在完成后将其合并回分支。开发人员将自己在该feature分支上测试其工作。现在有了测试人员，我们开始问这个问题 测试人员应在哪个分支上测试新功能？ 显然，有两种选择： 在单个要素分支上 在develop树枝上 测试开发分支 最初，我们认为这是肯定的方法，因为： develop自从开发开始，就将该功能与合并到分支的所有其他功能进行了测试。 可以早于任何时间检测到任何冲突 这使测试人员的工作变得容易，他始终只处理一个分支（develop）。他不需要询问开发人员哪个功能是哪个分支（功能分支是由相关开发者专有和自由管理的个人分支）。 最大的问题是： 该develop分支被错误污染。 当测试人员发现错误或冲突时，他会将错误报告给开发人员，由开发人员在开发分支上修复该问题（功能分支在合并后就被废弃了），此后可能需要进行更多修复。多个子序列的提交或合并（如果develop再次从分支上重新创建分支以修复错误），develop如果可能的话，使从分支回滚功能非常困难。develop在不同时间有多个功能合并并固定在分支上。当我们要创建仅包含develop分支中某些功能的发行版时，这会带来一个大问题 在功能分支上测试 因此，我们再次考虑并决定应该在功能分支上测试功能。在测试之前，我们将develop分支之间的更改合并到功能分支（赶上develop分支）。这很好： 您仍然可以与主流的其他功能一起测试该功能 进一步的开发（例如，错误修复，解决冲突）不会污染develop分支。 您可以轻松地决定不发布该功能，除非对其进行了全面测试和批准； 但是，有一些缺点 测试人员必须合并代码，如果有冲突（很有可能），他必须向开发人员寻求帮助。我们的测试人员专门从事测试，无法编码。 一个功能可以在不存在另一个新功能的情况下进行测试。例如，功能A和功能B都同时在测试中，由于这两个功能都没有合并到develop分支中，因此这两个功能互不了解。这意味着develop无论如何，当两个功能都合并到develop分支时，您将不得不再次对该分支进行测试。而且您必须记住将来要进行测试。 如果功能A和功能B均经过测试和批准，但在合并时发现冲突，则两个功能的开发人员都认为这不是他自己的错/工作，因为他的功能分支通过了测试。通信中存在额外的开销，有时解决冲突的人都会感到沮丧。 以上是我们的故事。在资源有限的情况下，我想避免在任何地方进行所有测试。我们仍在寻找更好的方法来解决这一问题。我很想听听其他团队如何处理这种情况。