Waiting on Multiple GitHub PR Merges

Question

Scenario: I fork a project and submit a PR on Feature A, and then another on Feature B. I want to continue working with both features while I'm waiting for the PRs to be merged (theoretically they might never be if the upstream is abandoned).

Updated Requirement: I’ll have to push the changes to my fork remote so that the CI will pick them up.

I thought of two possibilities: 1. Create a branch in my fork which I treat like master until upstream/master catches up and can be synced back to my fork, but is there a standard convention for naming such a branch? 2. Merging the feature branches into master on my fork, which would simplify loading, but would require a forced push to merge upstream/master later on, which I know is frowned upon.

What is the best way to handle this situation?

Answer 1

There is no particularly good approach to solve this. When the upstream project merges, squashes, or rebases your features A and B, they are creating new commits that are not part of any branch that you can work on right now. Therefore, if you continue work on top of your features, you will have to merge or rebase in the future. A force-push at some point is probably unavoidable if you want to track the upstream master, for example in order to create a pull request for a future feature C that depends on A and B.

Note that force-pushes are not in itself evil. Force-pushing makes life difficult for other people that are tracking your branch. E.g. force-pushing on a master branch that other people might have cloned is a no-no. Force-pushing on a feature branch under active development is perfectly fine. Especially during a pull request review, using force-pushing to clean up the commits in the pull request can sometimes be a best practice.

It might be best to avoid using the master branch for your own development. If possible, use a feature branch that you will rebase later, e.g. feature-C. If you need a personal pseudo-master branch, I'd name it after myself. However, no general convention exists for this case.

Answer 2

Create your 'continue working' branch (whatever that's going to be called), and cherry-pick the other PR changes in. (You could merge, but it'll get messy if you later need to address review comments in those PR branches.)

---- upstream/master
    \_ origin/pr-a
     \_ origin/pr-b
      \___ origin/continue-working

Later, when the PRs are merged, you can rebase continue-working, and carry on like nothing happened.

--------- upstream/master
    \_/| \  origin/pr-a
     \_| |  origin/pr-b
         \_ origin/continue-working

Answer 3

In a situation like this I usually create a local throw-away branch. It doesn't matter what you call it since it is private and it doesn't live for very long. In this branch you merge both branches from PR A and PR B. You can then continue working. If you create more commits in this throw-away branch they can easily be cherry picked into PR C once PR A and PR B have been merged.