I maintain a relatively popular github repo.
When a pull request is good to merge I usually ask the author to rebase it to a single commit before I merge it (especially when there have been multiple small edits).
Is this good git practice?
Is this acceptable/standard GitHub etiquette?
So some benefits:
- I get a nice clean commit history in the commit logs
- I don’t need to alter the commit myself
- It delegates some of the work
Some possible drawbacks:
- I’m not sure if this is good etiquette
- I’m not sure if this is a good git practice
- I’ve usually already asked for a few other changes – this is one more and I don’t want to discourage contributors.
5
As far as Git is concerned, it’s something of a holy war whether you should simply merge branches or rebase commits on the latest version of the branch you are merging into. There’s plenty of conversations about which is better if you do a quick search on Programmers.SE.
As to the etiquette behind it, lets deal with this from a practical perspective. When dealing with new code coming from someone else it’s always best to get them to either merge the latest changes from the branch or freshly rebase it before merging to ensure a clean merge. Remember, they wrote the code so they are usually by far the most qualified to deal with any merge/rebase conflicts. I personally don’t see a problem with it, and see this request all the time from other people. For me, if there’s no conflicts then I’ll often just do it myself since it’s a two second update that git can apply itself. But if there’s conflicts then I will always ask the original author of the code to deal with it themselves.
Also, for GitHub (at the minimum) specifically, they will display a link to your CONTRIBUTING file above any PR attempts so that makes a good place to outline your expectations and many projects do include that they will only merge up to date branches.
2