The thing about pull requests is that it makes known that there are changes that someone wants to bring into the project.
If the owner/maintainer wants to cherry pick parts of the pull request, they can do that from that pull request.
And just because there is a pull request does not mean that the maintainer is not allowed, or incapable, of doing a rebase.
So this is indicative of a style that may be wanted in the history.
You can always display the history without the merge history, or even the other way around.
git log --mergesgit log --no-merges
So it boils down to, I think:
- The project owner wanting to enforce, or not, a certain style of history
- The fact that you can get either set of information easily from Git itself, regardless.
You also mention that "A one-commit change is probably the most common case for pull requests" but I am not sure about that.
For one, the number of commits may be unknown due to the developers habits of doing micro-commits and then rebasing them. Also, it is common for me to see project owners asking for those commits to be squashed in the CONTRIBUTING.txt file, or other communication.
Edit: Of course, I can't answer the question of why doesn't X, Y and Z companies do something. Not sure anyone can, except for those entities.
git-merge mechanism:
Using git merge feature while on master merges the branch feature to master and produces a merge-commit (if the branch cannot be fast-forwarded) in the git history. To force a merge-commit being made, use the --no-ff option with merge.
Merge Pull Request mechanism:
When we start a Pull Request on GitHub, it creates a GitHub Issue where people can talk and discuss the commits in the PR before merging it. When a PR is merged on GitHub it does the exact same thing as git merge feature.
What should I do?
So, as far as history is concerned, there is no difference between the two.
And as far as contribution goes, your contributors will not have to do anything different for the two situations. They are the same (minus the nice little chat).
Best Practices:
And I was unable to find a best practices but logic says that PRs are not much helpful if there is only a single contributor to a repository.
@lxrec and @amon helped me reach this conclusion.
Best Answer
I do this quite frequently, for microservices other teams own, or for documentation changes to tech pubs. We have separate repos for individual microservices, with only a scrum team or two having merge permissions for each. I want my own team to review thoroughly before I waste the time of the owning team.
The easiest way I have found is to fork the repo into my private profile, then do all my work from a branch on my fork. I do a pull request against
masteron my fork first, then when that is approved, do a pull request againstmasteron the "official" repo.The reason I started doing it this way is our team is somewhat of a trusted innovator, so other teams would often just merge anything we sent them without questioning it. Doing the first pull request in a separate repo meant they couldn't merge it prematurely just by clicking a button. The permissions and visibility on both repos are easily controlled.
You don't have to do this with personal forks, you could create repos for longer-lived larger groups if that works for your use case. Perhaps one repo for everything from a certain contractor company, for example.