我正在寻找一些关于开发人员如何在新的测试环境中测试自己的功能分支的指导。我们已经建立了一个新的TEST服务器/TEST数据库，我们希望我们的开发人员在这个环境中测试他们的功能分支。这就是我们对工作流程的设想。
- 开发人员将从master分支创建他们的功能分支
- 一旦他们准备好测试他们的功能，他们将合并到开发分支(没有同行评审(，并从该开发分支构建和部署到test服务器
- 一旦他们对自己的测试感到满意，他们将在同行评审后，从他们的功能分支创建一个PR，合并到主中
这种方法可行吗？我们团队中有5到6名开发人员。目前，每个开发人员都直接从他们的功能分支部署到此TEST服务器，这会导致开发人员的更改被其他人覆盖。因此，我们考虑添加这个开发分支，以避免上述问题。我可以看到这种方法的一个问题是，开发人员A和开发人员B是否都想测试他们的更改，以及开发人员B的更改是否会导致测试服务器中的应用程序崩溃。然后，开发人员A必须等待他的测试，直到开发人员B修复测试环境。任何指向正确方向的指针都会有所帮助！
您的工作流程很好。一些建议：
- 显然，您可以随心所欲地调用分支名称，但是，我建议您将测试分支称为
develop以外的名称，因为该名称是Git Flow中使用的标准分支名称，它旨在作为新开发的起点，并且最终将始终合并到master中。熟悉Git Flow的人可能会认为develop的含义与你打算使用它的方式不同。我建议你把它称为next，这就是Git的维护人员在gitworkflow中所说的测试分支 - 定期从
master重置next分支，以便清除所有未进行剪切的测试代码。根据验证代码所需的时间，您可以缩短或延长重置频率。在我的公司，我们目前每周日重置next - 当开发人员为新工作从
master分支时，如果master早于上次重置next的时间，则当这些分支合并到next时，它们将从master引入所有新提交以及要测试的新提交。根据合并的方式，这可能会导致混淆(例如，在将PR转换为next的情况下(。如果您正在使用PR进行合并，并且其他提交混淆了更改列表，请考虑先将它们合并到最新的master中，然后合并它们自己的分支，以便它们可以在单独的合并中隔离自己的更改
提示：当一个开发人员破坏next分支的构建时，如果他们不能立即修复它，最简单的方法就是恢复分支的合并提交，这可以有效地撤消合并。