I just tested it, because I wasn’t sure. As of 2018-12-09:
- If you use
git mergeto merge a pull request (PR) from the command line, GitHub will detect that the PR’s commit(s) have been added to
master, and will automatically mark the PR as “merged”.
- If you instead use
git rebaseto 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