Dependent Task and Pull request

Question

I have following scenario.

• Three Tasks depends on one another.
• Now workflow for Git (VSTS) with visual studio has following things. ( Means it is decided by our team)
  • Before start working on any Task . Please create Branch of it then work. Create Pull request.
  • Now Pull request still is in pending state for approval. Developer want to start working on Task 2 which is depends on Task 1 how he create branch. As he need code that is present in Task 1 Branch and it is still not merged with main branch.

Answer 1

The branch for task2 should be created from the branch for task1, even though the branch for task1 has not been merged into master branch.

And after the PR completing, there usually has two ways to merge the branch for task2 into master branch: create a PR to merge branch for task2 directly; rebase the branch for task2 onto master branch and then create a PR.

Let's illustrate both ways by graphs. Assume feature1 is the branch for task1, and feature2 is the branch for task2. The commit history as below:

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

Since task2 is depend on the task1, so you should create feature2 branch from feature1 branch. Then develop and commit changes on feature2 branch. The commit history will be:

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

And when the PR has complete to merge feature1 branch into master branch, the commit history will be (commit M is the merge commit):

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

For creating another PR to merge feature2 branch into master branch, there usually has two ways as below:

Option 1: create a PR to merge feature2 branch into master branch directly

When the work on task2 (feature2 branch) is finihed, you can create another PR to merge feature2 into master branch directly.

And after the PR completing, the commit history will be:

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

Option 2: rebase feature2 branch onto master branch and then create a PR

Since master branch has already contains the changes for task1 (feature1 branch), you can rebase feature2 branch onto master branch by below command:

git rebase --onto master feature1 feature2

Then the commit history will be:

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

And then you can create a PR to merge feature2 branch into master branch. After the PR completing, the commit history will be:

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

Answer 2

Ideally this should not be happening if you design your Git workflows/sprints properly. If you do see this happen often, then I think you should view it as a workflow problem.

If you must deal with this, then one option you could try would be to rebase the task 2 branch on the task 1 branch. That is, treat the task 2 branch as being a spur from task 1, and not from master. Here is some Git code you might try:

# 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

You might use a variation of the above as well. The basic idea behind my suggestion is to make task 1 the new destination branch for task 2.