我们有一个 PL/SQL（Oracle DB 过程语言，但它并不重要）git 项目。我们有 develop 分支，其中包含所有更改，并且似乎是 PRO 当前状态（尽管使用 master 应该更好，但它已经存在多年了）。我们通常从 develop 创建分支，对这个分支做一些改变（假设它是 feature/JIRA-1234）。然后我们有 env-branch，代表 QA、集成、UAT 测试环境的状态（假设，它是其中之一，它是 env/qa）。我们将准备测试的功能合并到所需的 env 分支中。测试后，我们创建发布分支，收集准备在 PRO 中部署的所有功能。我们在阶段 env 上检查部署，修复安装问题（如果有），然后用发布标签标记该分支的最新提交，并将其传递给负责部署过程的 OPS 团队。
我们现在使用这种方法面临的一个问题是，feature/JIRA-1234 分支在合并到 env/qa、env/uat 等之后直到合并到发布时仍然“不受保护”分支。因此，我可以在有 6 次提交后将分支传递给 QA 团队，并将新内容推送到该分支，然后将其传递给 env/uat，例如，稍后甚至在合并到发布分支之前进行更改。因此，经过一段时间后，QA 工程师无法真正说他/她测试了最新 版本的分支。
我想可能会在某些事件发生之前以某种方式“锁定”功能分支以防止合并（例如“QA 通过”）。或者也许改变开发过程。有时，开发人员希望通过添加一个确实不应该进行测试的小修复来改进他们的代码，但后来证明是 PRO 中的一个错误。
我们使用 gitlab 作为审查和管理合并请求的工具。所以可能它有一些解决这个难题的工具，但到目前为止我还没有找到。
感谢任何建议！或者，您可以分享涵盖此类情况的文章的链接。
编辑：
我知道 git flow 方法。我不认为它对我们有用，因为我们无法将功能合并回 develop，因为即将发布的版本的范围在某个时间之前还不确定。所以我的测试功能无法发布，因为 biz 团队现在不想在 PRO 中看到它。这就是我们在 develop 方法方面没有 git flow 分支的原因。
答案 0 :(得分：0)
感谢@JoelFan，我终于了解了使用分支的方法。
经过一些谷歌搜索后，我发现除了 git-flow 进程外，还存在 github-flow 和 gitlab-flow。
第一个非常简单，适用于小型且快速推出的版本，而第二个为具有依赖于 env 的分支的 SAAS 类产品提供了一种方法。我认为通过一些额外的调整对我们的发布模型很有用。