Git流程发送功能进行测试，只部署特定的功能到live

我们正在努力处理Git流流程，并将功能部署到测试和实时环境中：

• 我们希望所有准备好进行测试的功能都组合起来并部署到测试环境中
• 我们只想在实时环境中部署特定的功能

我们使用Git流的方式存在问题：

开发人员A按照正常的gitflow流程从“开发”创建一个特性，并在一个新特性中进行开发。 当准备好进行测试时，他将自己的特性合并到“开发”分支中，并将“开发”分支部署到测试环境中

开发人员B随后遵循相同的过程。这两个特性现在都合并到“开发”分支中，并且这两个更改都在测试环境中可见

客户机在测试环境中进行测试，但只批准开发人员A所做的更改发布到实时环境中。 因此，他将从“开发”创建一个新的“发布”分支。 但这个问题是，这将包括开发人员B的更改。

仅从开发人员A发布更改的最佳实践是什么

目前，我们正在遵循下面的过程，这允许我们将每个功能发布到Live server。但一定有更好的办法吗

我们遵循正常的Gitflow设置，但我们也创建了一个名为“qa”的新分支，它将从主“分支”创建。 这是我们遵循的程序：

拉动最新的“发展”分支

使用gitflow从“开发”创建功能

在一个特性中进行所有开发

一旦准备好测试，

• 拉最新的“qa”分支
• 在“qa”部门时
• 将您的功能合并到“qa”中

将“qa”分支释放到qa服务器

如果需要进行任何错误修复，请从步骤3开始重复

如果客户端出于某种原因不再需要此功能，则需要将其删除

• 删除该功能
• 撤消与qa的合并

如果客户对测试满意，请选择您的特性，并按照git流程完成该特性。（这将合并到 “开发”）

选择developmentbranch，并使用GitFlow创建新版本

使用Gitflow完成发布（如果需要，可以捆绑多个发布）

什么时候可以上线

• 确保您在主分支中
• 如果可能，测试项目和更改
• 将所需的所有文件复制到Live server

但是通过创建这个“QA”分支，我们根本没有按照预期使用开发分支，这使得它变得多余

---

我通读了这些答案，但对我们没有多大帮助，或者我不理解并

修复您的流程，以便您将git merges to master与客户测试解耦。如果他们希望能够确定功能是否应该是活动的（并要求它们不存在），那么他们要么需要参与讨论以合并开发，或者，您应该使用功能开关来部署功能，但可以将其关闭，以便在功能不存在时显示。

4年后，我将尝试回答自己的问题。 尽管@AlBlue的另一个答案是100%正确的方法，但这并不总是可能的

下面是四个Gitflow选项，它们允许单独的测试环境，并且只允许合并到master中的特定功能：

• 如第一个问题所述，为集成测试创建一个单独的分支，并将每个特性合并到该分支中以获得批准。更多信息可以在这里找到 . 缺点是你会有很多分支，如果有其他选择的话，我不喜欢这个解决方案
• Cherry pick：经常合并到develop中，在develop上进行集成测试，一旦测试获得批准，Cherry pick应该进入发布/主版本的特性。（没有尝试过，但似乎是一项任务）
• 使用功能开关（如Alblue所述）
• “修复您的流程，以便将git merges与master与客户测试分离”——正如AlBlue在回答中所说的那样。这现在是我们的首选选项，因为我们现在已经对自动化部署进行了排序。对于每个功能，只需点击一个按钮即可创建一个单独的托管环境（Azure devops+Azure hosting），因此在将每个功能合并到develop之前，都需要对其进行测试

  ---

对我来说，一个功能只有在完全完成后才能完成并合并到

develope

。如果批准仍然悬而未决，那么这是完成批准所需的一个步骤。如果功能需要客户单独批准/撤销，为什么不直接从each

feature

分支在QA服务器上单独发布和测试它们？在您的示例中，在完成特性之前，但一旦它准备好进行测试，Dev A将把特性A分支直接推送到服务器，Dev B将对特性B执行相同的操作。这可能意味着QA服务器的repo现在将包含这些特性分支。在服务器上，您可以设置多个虚拟主机端点，其中每个功能分支都将被客户端签出以供评估（例如，客户端在一个url中检查功能A；在另一个url中查看功能B，等等）。获批的将遵循正常的

git流程

周期

develope>release>master

。

版本

甚至可以推送到集成测试主QA url，以便在最后一分钟测试所有一起工作的已批准功能。@Hugofereira，感谢您的回复！客户机的基础架构以及测试人员不允许多个实例进行测试。他们只有qa.site.com和live.site.com。他们想要