Gitlab 流程 Mono Repo 中的长期环境分支在 Azure 存储库中的拉取请求上不断增长提交日志

Question

我们最近从 IBM RTC 迁移到 Git，并面临分支策略的问题。我们过去在 RTC Jazz 中拥有三个流：开发流到登台以及生产中的登台流。在迁移到 Git（Azure Repos）时，我们将 RTC 组件（多个 Web 服务项目）放在一个大型单一存储库中，并选择了 GitLab Flow 分支策略，因为它强调长期生存的环境分支（每个环境三个分支）。由于我们有三个环境，我们希望跟踪哪些代码部署到哪个环境，并且在三个环境中可以有相同 Web 服务的不同版本。

我们决定的工作流程是开发人员从生产分支中分支出功能分支并开始工作，然后依次将他/她的功能分支合并到开发、暂存和最终生产。

一开始效果很好，但后来当我们提出 PR 将功能分支合并到开发和暂存分支之一时，不需要的提交就成为 PR 的一部分，因为功能分支还包含我们在开发和暂存分支之后合并到生产中的提交分支。

我不知道我们没有正确遵循 GitLab 流程，还是我们的工作流程存在问题？

限制：

1. 我们不能通过将开发合并到暂存以及暂存到生产来放松线性流程，因为我们有单一存储库，并且我们不想立即移动所有内容。
2. 我们希望在每个分支上保留每个环境的代码。

Answer 1

如果想通过 PR 将更改推送到目标分支，一般建议基于目标分支创建源分支。然后在源分支上进行更改并提高 PR 将更改合并到目标分支。在此过程中，尽可能避免从其他进程将一些其他更改推送到目标分支。这可以确保源分支与最新的目标分支保持同步，并避免冲突和意外更改。

---

对于您的情况，由于您基于

feature

分支创建了

production

分支，因此您可以尝试使用 cherry-pick 将所需的更改从

feature

复制到

development

或

staging

分支。

1. 将临时 PR 从

   feature

   提高到

   production

   。
   • 通过这种方式，PR 应该只包含在

     feature

     分支上所做的更改，这些更改应该是想要的更改。
   • 请勿在此 PR 上完成合并。
   • 您可以忽略此 PR 中报告的任何冲突。

2. 确保

   feature

   与要将所需更改合并到的目标分支（针对您的案例的

   development

   或

   staging

   分支）之间不存在冲突。如果存在冲突，请先解决。

3. 在临时 PR 的菜单上，选择“

   Cherry-pick

   ”选项。在弹出窗口中，选择要将所需更改合并到的目标分支（例如，

   development

   ）。然后点击“

   Cherry-pick

   ”按钮。

   

4. 点击“

   Cherry-pick

   ”按钮后，系统将执行以下操作。
   • 如果您选择从

     feature-on-development

     到

     feature

     进行精选更改，则会自动创建名为“

     development

     ”的分支。
   • 自动推广PR创建页面，让您将PR从

     feature-on-development

     提高到

     development

     。
   • 从这个新的 PR 中，您可以看到它只包含与之前的临时 PR 相同的更改。所有包含的更改都应该是您想要的。

5. 完成步骤

   #4

   创建的 PR。然后您可以删除任何临时分支并关闭/放弃任何临时 PR。

---