Git 发送功能进行测试的流程，仅将特定功能部署到现场
Git Flow process to send features for testing, only deploy specific feature to live
我们正在努力处理我们的 Git 流程，并将功能部署到我们的测试和实时环境：
- 我们希望所有准备好进行测试的功能都组合并部署到测试环境。
- 我们只想将特定功能部署到实时环境
我们使用方式的问题Git流程：
开发人员 A 按照正常的 gitflow 过程从 "develop" 创建一个功能，并在一个新功能中进行开发。
当准备好进行测试时，他将他的功能合并到 "develop" 分支，并将 "develop" 分支部署到测试环境。
开发人员 B 然后遵循相同的过程。这两个功能现已合并到 'develop' 分支中，并且两个更改在测试环境中可见。
客户端在测试环境中进行测试，但只批准开发人员A所做的更改发布到实时环境。
所以他将从 'develop' 创建一个新的 'release' 分支。
但是这个问题是，这将包括开发人员 B 的更改。
仅发布开发人员 A 的更改的最佳做法是什么？
目前我们正在遵循以下程序，这使我们能够将每个功能发布到 Live 服务器。但是一定有更好的方法吗？
我们遵循正常的 Git 流程设置，但我们还创建了一个名为 "qa" 的新分支，这将从主分支 "branch" 中创建。
这是我们遵循的程序：
- Pull latest "develop" branch
- Create feature from "develop" using gitflow
- Do all development in a feature
- Once ready for testing,
- pull latest "qa" branch
- while in the "qa" branch
- merge your feature into "qa"
- Release the "qa" branch to the QA server
- If any bug fixes need to be done, repeat from step 3
- If the client for some reason do not need this feature anymore, and it needs to be removed
- Delete the feature
- Undo your merge to qa
- If client happy with testing, select your feature, and follow the git flow process to finish the feature. (This will merge into
"develop")
- Select Development branch, and create new release using GitFlow
- Finish the Release using Gitflow (or bundle multiple releases if needed)
- When ready to go live
- make sure you are in the master branch
- if possible, test the project and changes
- copy all files needed to the Live server
但是通过创建这个 "QA" 分支，我们根本没有按预期使用开发分支，这使得它变得多余。
我通读了这些答案，但对我们没有太大帮助，或者我不明白here and here
修复您的流程，以便将 git 合并与客户测试分离。如果他们希望能够确定功能是否应该上线（并要求它们不存在），那么他们要么需要参与讨论以合并开发，要么您应该使用功能开关来允许您部署该功能，但能够将其关闭，以便在不存在时出现。
4年后我会尝试回答我自己的问题。
尽管@AlBlue 的另一个答案是 100% 正确的做法，但这并不总是可行的。
这里有四个 Gitflow 选项，允许单独的测试环境，并且只允许合并的特定功能合并到 master 中：
- 如初始问题所述，为集成测试创建一个单独的分支，并将每个功能合并到该分支中以供批准。可以在此处找到更多信息
.缺点是你会有很多分支，如果其他选项可行的话，我不喜欢这个解决方案。
- Cherry pick：经常合并到 develop 中，在 develop 上进行集成测试，一旦测试被批准，cherry pick 应该进入 release/master 的功能。 （没试过，但似乎是一个任务）
- 使用功能开关（如 Alblue 所述）
- "Fix your process so that you decouple the git merges to master with the customer testing" - 正如 AlBlue 在他的回答中所说的那样。现在这是我们的首选，因为我们现在已经对自动化部署进行了排序。对于每个功能，只需单击一个按钮（Azure devops + Azure 托管）即可创建一个单独的托管环境，因此每个功能都需要在合并到开发之前进行测试。
我们正在努力处理我们的 Git 流程，并将功能部署到我们的测试和实时环境：
- 我们希望所有准备好进行测试的功能都组合并部署到测试环境。
- 我们只想将特定功能部署到实时环境
我们使用方式的问题Git流程：
开发人员 A 按照正常的 gitflow 过程从 "develop" 创建一个功能，并在一个新功能中进行开发。 当准备好进行测试时，他将他的功能合并到 "develop" 分支，并将 "develop" 分支部署到测试环境。
开发人员 B 然后遵循相同的过程。这两个功能现已合并到 'develop' 分支中，并且两个更改在测试环境中可见。
客户端在测试环境中进行测试，但只批准开发人员A所做的更改发布到实时环境。 所以他将从 'develop' 创建一个新的 'release' 分支。 但是这个问题是，这将包括开发人员 B 的更改。
仅发布开发人员 A 的更改的最佳做法是什么？
目前我们正在遵循以下程序，这使我们能够将每个功能发布到 Live 服务器。但是一定有更好的方法吗？
我们遵循正常的 Git 流程设置，但我们还创建了一个名为 "qa" 的新分支，这将从主分支 "branch" 中创建。 这是我们遵循的程序：
- Pull latest "develop" branch
- Create feature from "develop" using gitflow
- Do all development in a feature
- Once ready for testing,
- pull latest "qa" branch
- while in the "qa" branch
- merge your feature into "qa"
- Release the "qa" branch to the QA server
- If any bug fixes need to be done, repeat from step 3
- If the client for some reason do not need this feature anymore, and it needs to be removed
- Delete the feature
- Undo your merge to qa
- If client happy with testing, select your feature, and follow the git flow process to finish the feature. (This will merge into "develop")
- Select Development branch, and create new release using GitFlow
- Finish the Release using Gitflow (or bundle multiple releases if needed)
- When ready to go live
- make sure you are in the master branch
- if possible, test the project and changes
- copy all files needed to the Live server
但是通过创建这个 "QA" 分支，我们根本没有按预期使用开发分支，这使得它变得多余。
我通读了这些答案，但对我们没有太大帮助，或者我不明白here and here
修复您的流程，以便将 git 合并与客户测试分离。如果他们希望能够确定功能是否应该上线（并要求它们不存在），那么他们要么需要参与讨论以合并开发，要么您应该使用功能开关来允许您部署该功能，但能够将其关闭，以便在不存在时出现。
4年后我会尝试回答我自己的问题。 尽管@AlBlue 的另一个答案是 100% 正确的做法，但这并不总是可行的。
这里有四个 Gitflow 选项，允许单独的测试环境，并且只允许合并的特定功能合并到 master 中：
- 如初始问题所述，为集成测试创建一个单独的分支，并将每个功能合并到该分支中以供批准。可以在此处找到更多信息
- Cherry pick：经常合并到 develop 中，在 develop 上进行集成测试，一旦测试被批准，cherry pick 应该进入 release/master 的功能。 （没试过，但似乎是一个任务）
- 使用功能开关（如 Alblue 所述）
- "Fix your process so that you decouple the git merges to master with the customer testing" - 正如 AlBlue 在他的回答中所说的那样。现在这是我们的首选，因为我们现在已经对自动化部署进行了排序。对于每个功能，只需单击一个按钮（Azure devops + Azure 托管）即可创建一个单独的托管环境，因此每个功能都需要在合并到开发之前进行测试。