0

我开始与其他开发人员合作开展一个项目，到目前为止我大部分时间都是独自工作。

我们的 repo 托管在 GitLab 上，我正在尝试弄清楚如何为团队设置一个简单的 git 工作流。

我们有一个master分支，其中包含用于生产的代码，我希望团队成员处理功能分支，然后合并到主分支。

现在，当一个人想要解决一个问题时，它会创建一个带有分支的合并请求并将代码推送到它。准备好后，他们会要求审核，如果审核通过，我会将功能分支合并到master. 到目前为止，一切都很好。

我现在无法解决的问题是：如果团队成员想要继续处理另一个依赖于之前正在合并的问题的问题，我如何查看依赖合并请求的代码？

在这种情况下，我们将有一个master分支、一个issue-1基于的分支master和一个issue-2基于的分支issue-1。

如果两个合并请求的目标是master，则在审查 的更改时，issue-2我还必须筛选 的更改issue-1，我应该已经在issue-1合并请求时单独审查了这些更改。

是否可以保留master两个 MR 的目标分支，但issue-1用作 diff 的基础issue-2？

我知道有一个合并依赖高级功能，但我认为它不能解决这个特定问题。

预先感谢您的帮助。

4

1 回答 1

1

在这种情况下，我们将有一个 master 分支，一个基于 master 的 issue-1 分支和一个基于 issue-1 的 issue-2 分支。

要作为合并请求提交的分支不能基于要作为合并请求提交的另一个分支。

工作的人issue-2当然可以从它分支issue-1，以便不必复制这些提交，但随后issue-2必须重新基于master，这必须在精确的时间完成 - 即，在合并issue-1之后master但在最终提交issue-2批准之前.

然而，最好不要那样做。如果issue-2真的依赖于issue-1它们，它们一开始就不应该是不同的分支/合并请求。一般来说，合并请求分支理想情况下需要是“正交的”，即它们应该对master.

于 2021-09-08T18:41:48.633 回答