Should I branch from a branch when waiting on reviewer to merge a pull request?

Viewed 1108

So, I created a pull request in my ticket-3 branch and my reviewer reviewed and found one minor thing for me to change. I've made this change, pushed the commit, and now just waiting for the reviewer to approve the merge request. I'm confident that no other changes are to be made for the pull request and would like to work on a feature in my app.

What is the best way to go about this? Should I create another branch from my ticket-3 branch? If I do this, what happens to the new branch once the ticket-3 branch has merged with the main branch?

I'm sure there is a common practice for this, however I haven't had a dev job yet so not sure what it could be. I also found this, but the answer doesn't appear to be a branched branch...

Thanks and appreciate the help.

3 Answers

If you make a branch from ticket-3, while ticket-3 is merged (non-fast-forward) with main, you will have to rebase it on top of main eventually.

 m--m--m--m--m---M    (main)
     \          /
      3--3--3--3      (ticket-3)
                \
                 4--4 (ticket-4)

 git rebase --onto main ticket-3 ticket-4

 m--m--m--m--m---M         (main)
     \          / \
      3--3--3--3   4'--4'  (ticket-4)
               | 
           (ticket-3)

If ticket-3 is merged in a fast-forward manner, you don't have anything to do.

 m--m--3--3--3--3      (main, ticket-3)
                 \
                  4--4 (ticket-4)

Do not start on a ticket that depends upon a pending pull request. This can cause serious complications, especially if the pull request is rejected or greatly altered. Feature branches need to be independent. If the dependency is so tight that you cannot proceed without the earlier pull request, this should be part of that pull request (one pull request can satisfy multiple tickets).

I handle this issue the same way I handle the issue that others may work on master while I am doing work on a dev branch.

checkout and pull master to get up-to-date master

create dev1 branch and work on dev1 branch.

Before pushing dev1, merge the current top of master into dev1

(checkout and pull master. checkout dev1. "git merge master" to merge master changes into dev1)

Push dev1 and make a pull request.

Got more work to do? Check out master and create dev2 branch from master. During this period my dev1 gets merged into master. So now go get the top of master as described above, and merge my dev1 changes from master into dev2, just as described above.

Note: This depends on dev2 not requiring the changes in dev1.

As noted in other answers, if dev2 requires dev1 and dev1 is not merged, it can be handled, but gets more complicated and the best answer depends on the situation.

Related