我们正在努力解决 Git Flow 流程，并将功能部署到我们的测试和实时环境：
- 我们希望所有已准备好测试的功能都可以combined并部署到测试环境。
- 我们只想部署具体特征到现场环境
我们使用 Git Flow 的方式存在的问题：
开发人员 A 按照正常的 gitflow 流程从“develop”创建功能，并在新功能中进行开发。
当准备好测试时，他将其功能合并到“开发”分支中，并将“开发”分支部署到测试环境。
开发者 B 随后遵循相同的流程。这两个功能现在都合并到“开发”分支中，并且这两个更改在测试环境中都可见。
客户在测试环境中进行测试，但仅批准开发人员 A 所做的更改发布到实时环境。
因此，他将从“开发”创建一个新的“发布”分支。但这个问题是，这将包括开发者 B 的更改。
仅发布开发人员 A 的更改的最佳实践是什么？
目前，我们正在遵循以下过程，这使我们能够将每个功能发布到实时服务器。但一定有更好的办法吗？
我们遵循正常的 Gitflow 设置，但我们还创建一个名为“qa”的新分支，这将从主“分支”创建。
这是我们遵循的程序：
- 拉最新的“开发”分支
- 使用 gitflow 从“开发”创建功能
- 在一个功能中进行所有开发
- Once ready for testing,
- 拉最新的“qa”分支
- 在“qa”分支中
- 将您的功能合并到“qa”中
- 将“qa”分支发布到QA服务器
- 如果需要修复任何错误，请从步骤 3 开始重复
- If the client for some reason do not need this feature anymore, and it needs to be removed
- 如果客户对测试感到满意，请选择您的功能，然后按照 git 流程完成该功能。 （这将合并到
“发展”）
- 选择开发分支，并使用 GitFlow 创建新版本
- 使用 Gitflow 完成发布（或根据需要捆绑多个版本）
- When ready to go live
- 确保您在主分支中
- 如果可能的话，测试项目并进行更改
- 将所有需要的文件复制到Live服务器
但是通过创建这个“QA”分支，我们根本没有按照其预期使用开发分支，从而使其变得多余。
我通读了这些答案，但对我们没有太大帮助，或者我不明白here https://stackoverflow.com/questions/13887454/git-flow-releasing-selected-features and here https://stackoverflow.com/questions/8579056/multiple-development-branches-with-git-flow
四年后我会尝试回答我自己的问题。
尽管 @AlBlue 的另一个答案是 100% 正确的方法，但它并不总是可能的。
以下是四个 Gitflow 选项，可用于单独的测试环境，并仅允许将特定功能合并到 master 中：
- 正如在最初的问题中提到的，创建一个单独的分支用于集成测试，并将每个功能合并到该分支中以供批准。更多信息可以在这里找到Git 分支模型策略 https://stackoverflow.com/questions/38048843/git-branching-model-strategy。缺点是你会有很多分支，如果其他选项是可能的，我不喜欢这个解决方案。
- Cherry pick：经常合并到开发中，在开发上进行集成测试，一旦测试获得批准，就应该选择应该进入发布/主版本的功能。 （没试过，但似乎是一个任务）
- 使用功能开关（正如 Alblue 提到的）
- “修复你的流程，以便将 git 合并到 master 与客户测试分离”——正如 AlBlue 在他的回答中所说的那样。现在这是我们的首选选项，因为我们现在已经对自动化部署进行了排序。对于每个功能，只需单击一个按钮即可创建单独的托管环境（Azure devops + Azure 托管），因此每个功能在合并到开发之前都需要进行测试。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
