Add commits to a merged branch and start a new pull request

Question

Here's how things have gone so far:

1. Committed some work on branch A;
2. Submitted a Pull Request on branch A;
3. Pull Request has been merged upstream;

Now, I want to add some work to branch A. Is it possible for the existing Pull Request to be reopened so that the extra commits can be added, then remerged again? If not, how can I do this in a clean way? I thought about creating another branch and open a Pull Request from that one, but it doesn't seem right, extra work should be committed to the same branch.

Answer 1

Quick answer:

No, you can't re-open the pull request if it was merged, and if you could you shouldn't anyway.

TL;DR:

Usually you submit a pull request when your changes add some value (functional/non-functional) to the underlying code base. Value can be a simple log statement, a performance fix or a big feature, but a pull request is usually requested when you have a piece of work that doesn't depend on follow up changes.

Think of it, do you feel safe merging a pull request, knowing that the rest of the code could possibly never come through, leaving your code base incomplete? I personally never merge progressive branches unless I have no other choice. I'm trying to remember when I did this the last time (and I believe I did) but I don't recall.

Scenarios where you might want to do so:

• Someone else needs my changes, I'm blocking someone: if this is the case, why don't the other colleague pull the changes from your repo, or you can even work on a feature branch away from the releasable code base.

• You want earlier feedback: it's fine to have your code reviewed as soon as possible. If you want other people's input, state on the pull request that it shouldn't be merged, and you can add all the commits you want, and people suggest changes while you are coding the feature. This is not the most orthodox usage of a pull request but why not? Still better than merge half a feature.

• Some specs have changed and I need to implement them: it should be a new pull request. You did your work right the first time, so you did everything ok. This is fine if you're taking an agile approach in your project, and you make a lot of changes in short intervals of time. As long as your first pull request was accepted and it was correct (added something deliverable) you should be fine creating another pull request -> New requirements.

In either case you can continue working on your branch and open another pull request later. Since a pull request is just a "patch request" from the difference between two branches, you are ok.

Please let me know if there's another use case that would prompt you to submit a pull request in the conditions you described. I'll be happy to add reasoning for those as well.

PS: Make sure you fast-forward or rebase with your target branch before doing more work on it, it will save you a lot of work later on in merge conflicts, etc.