Updating a git pull request after a local rebase

Question

I recently ran into a situation where my pull request for a bug fix got messed up when I rebase from upstream locally, and then tried to push to my local PR on github. I wonder if I was going the right way, or that my workflow needs to be altered.

Basically, I followed this workflow:

• fork on github
• clone on local machine. Set origin (automatically) and upstream remotes.
• create fix branch.
• edit files.
• git push -u origin fix and submit a PR from this branch.
• in the mean time, one of the files in my fix got updated in the main repository. So I git fetch upstream; git merge upstream/master
• I update my origin/master: git push.
• I then git rebase master on my fix branch locally, manually merging them because of a conflict. git add; git rebase --continue.
• I then tried git push and that's where things went wrong. There doesn't seem to be a nice clean way to get that rebase fix branch into my PR.

So I wondered if I missed a step, or whether I should alter a step. I'm not sure if the git push origin was correct, or whether it needs to be more specific (e.g., with the branch name). Should/could I have tried something with git push --force in that last step (part of the PR was in my github repository, but very likely nowhere else pulled)?

Answer 1

Don't introduce merges inside pull requests. The proper workflow is this:

• Fork
• Clone
• Branch
• [hardcore coding work]
• [commit(s)]
• Rebase (to upstream/master), e.g. using git pull --rebase upstream master
• Push
• Create a pull request.

That way you avoid merge commits and end up with clean commits in your pull request which are based on the current master of the upstream repository.

If you pushed before the rebase, you have to perform a forced push using -f to push again after rebasing since you rewrite history during the rebase.

Something worth to keep in mind: Merges (that are not fast-forward or rebases) should never occur in simple fix/feature branches - just like you should never rewrite history in your "main" branches which others might base own work on.

Answer 2

Should/could I have tried something with git push --force in that last step (part of the PR was in my github repository, but very likely nowhere else pulled)?

Yes. You need to force-push a branch if your local branch is not a descendant of the remote branch, which it is not after you rebased it.

You should be aware of the consequences of a forced push though for other developers that may already have the overwritten changes, I do not recommend it: Better use a simple pull to bring in the upstream changes.