I just tested it, because I wasn’t sure. As of 2018-12-09:
- If you use
git merge
to merge a pull request (PR) from the command line, GitHub will detect that the PR’s commit(s) have been added tomaster
, and will automatically mark the PR as “merged”. - If you instead use
git rebase
to move the PR branch onto master, GitHub will not automatically mark the PR as merged.
This makes sense, because rebase
doesn’t actually modify the existing commit(s) in the PR. Instead, it creates new commit(s) that make the same changes the PR’s commits would have made if merged. So if you want to rebase or squash, do so from the Web interface. (Or, alternatively, this tool and its corresponding blog post — although please note that I haven’t tried it myself. Let me know if you do!)
I tried these with PRs in a single repo. Please chime in if you have any experience with merging PRs from a fork into a parent.
(And one final note: I discovered the hard way that git rebase
won’t preserve empty commits. That is because it cares about the changes, so a commit that makes no changes isn’t of interest to rebase
.)