Git 合并请求顺序

Question

我有 3 个分支 1.master 2. feature-auth 3. feature-operations。 branch 2 and 3 由 master.

制作

我在 feature-auth 工作并提出了合并请求。它仍然悬而未决。现在我想在从 master 创建的 feature-operations 中工作。现在问题是 feature-auth 仍然没有合并，我想在 feature-operation 中使用它的一些功能。那么解决这个锁的最好方法是什么？我应该从 feature-auth 创建 feature-operation 这个分支吗？虽然我在某处读到理想情况下所有分支都应该由 master 制作。

Answer 1

您可能会考虑在 feature-auth 之上重新设置 feature-operation，假设您是唯一一个在该功能分支上工作的人..

这样，您将受益于 feature-auth 的所有 commits/features，并且可以继续 feature-operation 的工作。

git checkout feature-operation
git rebase feature-auth
git push --force

while I read somewhere that Ideally all branches should be made from master.

这不是强制性的。

在您的情况下，您可以从：

至：

m--m--m--m--m  (master)
    \          / (pending MR)
     fa--fa--fa
               \
                fo'--fo'--fo' (feature-operation rebased)

OP 添加：

for example I have done working on feature-operation and still feature-auth is not accepted.
Then after completing work and before making a merge of feature-operation as well I have to rebase to master?

如果 feature-operation 基于 feature-auth 工作，您将不得不等待 feature-auth 被合并，然后（确实）在 feature-operation已更新 master.

并且：

So I should not push any changes to feature-operation until master is not updated? Or just before merge request?

当您在 feature-operation 上工作时，您可以根据需要在您的远程存储库上多次推送该工作。
一旦 feature-auth 合并到 master，您将 feature-operation 变基到 master 之上（在 master 分支上的 git pull 之后），并且您git push --force 你的 feature-operation rebased 分支，并继续工作（或者，如果你已经完成，做一个 MR）

Answer 2

在我看来，功能分支应该从它们将被合并到的同一个分支中出现。如果 feature b 依赖于 feature a，它们可能不应该是不同的分支和不同的 PR。

将 feature b 变基到 feature a 可能意味着您在 feature b 上的 PR 包括所有 feature a，这是错误的并且对批准过程不公平。更不用说强推了，那是个不好的兆头。

在我看来，如果 feature b 需要 feature a 拥有的东西，你应该挑选它。

Answer 3

我不是纯粹主义者，我不喜欢变基；我喜欢简单的事情，但我也没有代码审查委员会，只有队友。

我会采用@VonC的分支图，将master分支到fa，当fa完成你满意的时候，将fa分支到fo。无需变基。

如果前面的任何分支中有任何更改实现了您要使用的功能，或者对测试很重要，请尽可能多地将 fa 或 master 合并到 fo 中。如果不出意外，那将简化最终合并。

fo 到 master 的最终合并将比其他方式更接近 master，使所有相关人员的最终审查更简单。

Git 合并请求顺序

Git merge request sequence

git

github

bitbucket

gitlab