在工作中，我们现在正在使用 GitHub，并使用该 GitHub 流程。我对 GitHub Flow 的理解是有 master 分支和 feature 分支。与 git flow 不同，没有开发分支。
这在我们已经完成的项目上非常有效，并且简化了事情。
但是，对于我们的产品，我们有一个开发和生产环境。对于生产环境，我们使用master分支，而对于开发环境，我们不知道该怎么做？
我能想到的唯一想法是：
目前，对于需要开发环境的项目，我们本质上是在使用 git flow（功能 -> 开发 -> 主控）。
您认为我的想法是否明智，如果不是，您会推荐什么？
编辑：
澄清一下，我问的是使用GitHub Flow而不是git flow实现开发的最佳方式。
根据我的经验，具有多个环境的 GitHub Flow 就是这样工作的。合并到 master 不会自动部署到生产环境。相反，合并到 master 会创建一个构建工件，该工件可以通过使用 ChatOps 工具的环境进行升级。
例如， push tomaster创建一个名为 的构建工件my-service-47cbd6c，它是服务名称和短提交哈希的组合。这被推送到某种工件存储库。然后可以使用诸如 ChatOps 风格的斜杠命令之类的工具将工件部署到各种环境中以触发 deloy。例如，该工具还可以进行检查以确保不会跳过测试环境。最后，将工件提升为生产。
因此，对于您使用 GitHub Actions 的用例，我的建议是：
master创建构建工件并自动将其部署到开发环境。最近（2021 年 2 月），您可以：
您现在可以使用环境保护规则限制哪些分支可以部署到环境中。
当作业尝试部署到配置了部署分支的环境时，Actions 将根据配置检查 github.ref 的值，如果不匹配，作业将失败并停止运行。
部署分支规则可以配置为允许：
- 所有分支——存储库中的任何分支都可以部署
- 受保护的分支- 仅具有保护规则的分支
- 选定的分支- 匹配一组名称模式的分支
这意味着您可以定义要在开发环境中部署的作业，并且作为条件，该作业仅在从给定分支推送的提交触发时才会运行（master在您的情况下）
对于任何面临相同问题或想要简化他们的流程远离 gitflow 的人，我建议看看这篇文章。虽然它没有明确谈论 Github 流，但它确实有效地为 OP 提供了一种解决方案。
纯粹的人可能会认为这不是严格意义上的 Gitflow，但在我看来，这是一个简单的调整，使部署和 CI/CD 策略在 git 中更加明确。我更喜欢采用这种方法，而不是在工具中添加一些魔法，这会使开发人员更难以遵循和理解流程。
我认为Gitflow 介绍的编写也相当实用：
不同的团队可能有不同的部署策略。对于某些人来说，最好部署到专门配置的测试环境中。对于其他人来说，直接部署到生产环境可能是更好的选择......
文章中的图表总结得很好：
所以这里我们有 Master == Gitflow main，有用的补充是临时发布分支，您可以从中部署到其他环境，例如开发。值得考虑的是您选择将此临时分支称为什么，在上面它被认为是一个发布，在您的过程中它可能是一个测试分支等。
您可以接受或离开挤压和标记，并且工具将在团队之间发生变化。同样，您可能关心也可能不关心实际的版本号。
这与 VonC 的答案相距一百万英里，不同之处在于流程定义更严格，更倾向于让多个开发人员合并到一个分支并应用修复，以便为生产准备好新版本。很可能您通过命名约定配置了这个临时分支的部署，如他的回答。
Nathan，添加一个开发分支是个好主意，您可以在新分支中处理开发更改并在开发环境中测试它们，在获得签名以转移到生产环境后，您可以在主分支中合并您的更改。
不要忘记在合并的主分支上执行回归测试以测试旧功能和新功能在发布您的代码以在生产中安装之前都可以正常工作
