从属任务和请求请求

Question

我有以下情况。

• 三个任务相互依赖。
• 现在使用Visual Studio的Git（VSTS）工作流程具有以下功能。 （意味着这是由我们的团队决定的）
  • 开始执行任何Task之前。请创建它的分支，然后工作。创建请求请求。
  • 现在，拉取请求仍处于待审批状态。开发人员希望开始处理任务2，这取决于任务1如何创建分支。因为他需要任务1分支中存在的代码，但仍未与主分支合并。

Answer 1

应该从task1的分支中创建task2的分支，即使task1的分支尚未合并到master分支中。

PR完成后，通常有两种方法可以将task2的分支合并到master分支中：创建PR以直接合并task2的分支； 将task2的分支重新建立到master分支上，然后创建PR 。

让我们用图形来说明这两种方式。假设feature1是task1的分支，而feature2是task2的分支。提交历史如下：

...---A---B---C  master
           \
            D---F---G   feature1

由于task2依赖于task1，因此您应该从feature2分支创建feature1分支。然后在feature2分支上开发并提交更改。提交历史将为：

...---A---B---C  master
           \
            D---F---G   feature1
                     \
                      H---I  feature2

当PR完成将feature1分支合并到master分支中时，提交历史将为（commit M是合并提交）：

...---A---B---C-------M  master
           \         /
            D---F---G   feature1
                     \
                      H---I  feature2

要创建另一个PR以将feature2分支合并到master分支中，通常有以下两种方法：

选项1：创建PR，将Feature2分支直接合并到主分支中

完成task2（feature2分支）的工作后，您可以创建另一个PR以将feature2直接合并到master分支中。

PR完成后，提交历史将为：

...---A---B---C-------M-------N  master
           \         /       /
            D---F---G---H---I   feature2
                    |
                 feature1

选项2：将feature2分支重新建立到主分支上，然后创建PR

由于master分支已经包含对task1的更改（feature1分支），因此可以通过以下命令将feature2分支基于master分支：

git rebase --onto master feature1 feature2

那么提交历史将是：

                        H'---I'  feature2
                       /
...---A---B---C-------M  master
           \         /
            D---F---G   feature1

然后您可以创建PR，以将feature2分支合并到master分支中。 PR完成后，提交历史记录将为：

                        H'---I'  feature2
                       /      \
...---A---B---C-------M--------N  master
           \         /
            D---F---G   feature1

Answer 2

理想情况下，如果您正确设计Git工作流程/冲刺，就不会发生这种情况。如果您确实经常看到这种情况，那么我认为您应该将其视为工作流问题。

如果必须处理此问题，则可以尝试的一种方法是将任务2分支重新建立在任务1分支上。也就是说，将任务2分支视为对任务1的刺激，而不是对主人的刺激。这是您可以尝试的一些Git代码：

# from task1
git checkout -b task2
# work work work ... complete the task
git rebase task1
# then end task2 by merging into task1, not master
git checkout task1
git merge task2

您也可以使用上述内容的变体。我建议的基本思想是使任务1成为任务2的新目标分支。