I have been using GitHub for quite some time now and I usually used to push my feature-branches and then start a Pull Request which I myself merged. I found it helped me keep track of where I merged branches.
But recently I have been reading more and more about how Git works and I realised that I can use the merge-commits to refer to when I merged branches.
So, what should I do when merging a feature-branch into master:
Perform a merge-commit on master and then push it upstream OR Push the local branch and start a Pull Request?
I have read Introducing Pull Requests for a 2 person team – merge my own requests? and Whats the work flow with 2 people on a project and Should I open pull requests from a branch on the official repo or my fork? but none of them seem to answer what I am looking for.
Best Answer
git-merge mechanism:
Using
git merge featurewhile on master merges the branchfeaturetomasterand produces amerge-commit(if the branch cannot be fast-forwarded) in the git history. To force amerge-commitbeing made, use the--no-ffoption withmerge.Merge Pull Request mechanism:
When we start a Pull Request on GitHub, it creates a
GitHub Issuewhere 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 asgit 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.