Git CI/CD 的分支和环境开发过程
Git Branches & Environments Development Process for CI/CD
我有一个“开发过程”的问题，希望得到一些经验和意见。
我正在与一家拥有典型 dev、staging 和 production 环境的公司合作。有十几个不同的 git 回购协议和一个与 CI/CD.
的每个环境相关的分支
每天大约有 15 名开发人员跨分支机构处理任务。
dev env 用于 QA，staging 是随时可部署的生产环境。这都是正常的业务，环境没有问题。
这是棘手的地方，将代码与 git 从一个环境合并到另一个环境的方向和过程：
dev 永远不会直接合并到 staging。当前的过程是使用 cherry-pick 从 dev -> staging 获取代码，这样在 dev env 的 QA 步骤中没有来自其他开发人员的任何东西被合并进入 staging 不应该的。
这是一个真正的 messy/risky 过程，IMO，因为如果你 [开发人员] 正在挑选你的提交从 dev 到 staging 那么你可能会错过提交并且你可以想象一下那会引起的头痛！
是否有更好的流程可以用于我们的环境建模？
我知道这是基于意见的，可能不是 everyone/situation 的正确 答案。 （感谢@adam 提到 git-flow。）
环境：
- 制作
- 分期
- 开发
Staging 旨在成为一个稳定的 release/environment，可以随时部署到 master。 Dev 是 staging.
之前的 QA 和 dev 环境
Git 分支机构：
- 硕士（生产）
- 分期
- 开发
- 功能/[名称]错误修复/[名称]等（遵循git-流程模式）
发展process/flow：
开发人员被分配了一张票。开发人员从 staging 分支签出一个新的 feature/bugfix 分支。开发人员在 feature/bugfix 分支和 MR/PR 分支上做他的工作，因此它可以在 dev 环境中进行 QA。工单通过 QA 后，开发人员将使用 feature/bugfix -> staging 打开 MR/PR。 feature/bugfix合并成staging后可以丢弃
分支机构的内务管理需要定期保持最新 - 最重要的是，dev 需要经常根据 staging 进行调整，以保持 QA 环境的健康和最新。
我有一个“开发过程”的问题，希望得到一些经验和意见。
我正在与一家拥有典型 dev、staging 和 production 环境的公司合作。有十几个不同的 git 回购协议和一个与 CI/CD.
每天大约有 15 名开发人员跨分支机构处理任务。
dev env 用于 QA，staging 是随时可部署的生产环境。这都是正常的业务，环境没有问题。
这是棘手的地方，将代码与 git 从一个环境合并到另一个环境的方向和过程：
dev 永远不会直接合并到 staging。当前的过程是使用 cherry-pick 从 dev -> staging 获取代码，这样在 dev env 的 QA 步骤中没有来自其他开发人员的任何东西被合并进入 staging 不应该的。
这是一个真正的 messy/risky 过程，IMO，因为如果你 [开发人员] 正在挑选你的提交从 dev 到 staging 那么你可能会错过提交并且你可以想象一下那会引起的头痛！
是否有更好的流程可以用于我们的环境建模？
我知道这是基于意见的，可能不是 everyone/situation 的正确 答案。 （感谢@adam 提到 git-flow。）
环境：
- 制作
- 分期
- 开发
Staging 旨在成为一个稳定的 release/environment，可以随时部署到 master。 Dev 是 staging.
之前的 QA 和 dev 环境Git 分支机构：
- 硕士（生产）
- 分期
- 开发
- 功能/[名称]错误修复/[名称]等（遵循git-流程模式）
发展process/flow：
开发人员被分配了一张票。开发人员从 staging 分支签出一个新的 feature/bugfix 分支。开发人员在 feature/bugfix 分支和 MR/PR 分支上做他的工作，因此它可以在 dev 环境中进行 QA。工单通过 QA 后，开发人员将使用 feature/bugfix -> staging 打开 MR/PR。 feature/bugfix合并成staging后可以丢弃
分支机构的内务管理需要定期保持最新 - 最重要的是，dev 需要经常根据 staging 进行调整，以保持 QA 环境的健康和最新。