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.

  • 2
    What exactly do you feel is lacking from those answers? – RubberDuck Dec 12 '15 at 17:07
  • The first one talks about it from the sense that pull requests are meant to be peer reviewed. The second one offers a workflow. The third one isn't even related. – Ashhar Hasan Dec 12 '15 at 17:11
  • 1
    I am looking at this from a Best Practices or How to maintain a good git history point of view. – Ashhar Hasan Dec 12 '15 at 17:11
  • 1
    When I merge a PR, I do so by merging the branch locally. This allows me to make sure the merge applies cleanly, and to re-run tests before publishing the result. GitHub's Pull Requests are just a formalization of this workflow, Git itself does not have a concept of PRs. – amon Dec 12 '15 at 17:15
  • 2
    When a PR gets merged it produces a merge commit on master, so I don't think this makes any difference to the git history. Thus I don't think there is any reason to use one or the other aside from your personal preference between the command line and the Github UI. – Ixrec Dec 12 '15 at 17:18

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 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 person on the repository.

@lxrec and @amon helped me reach this conclusion.

  • 4
    Tip: git merge might not record a merge commit if it can do a “fast forward”. To force a merge commit, you can add the --no-ff option. – amon Dec 12 '15 at 18:03
  • I prefer doing git-merge on local rather than doing it on githuib.com, if I would have to anything such on github.com I would prefer not to do directly on master branch, I would rather take non-master branch which can first be set on staging mode before making it available for production . – Ciasto piekarz Jan 30 '18 at 3:09

As Ashhar said, technically and history-wise there's no difference. For projects with a small team I prefer merging directly instead of the extra step of creating a PR. However, when a feature needs review/feedback or when it's a WIP and more than one person will be working on it I tend to open a PR and add a list of tasks to the PR's description.

Note that git merge might use fast-forward if there are no changes to master, so you might want to use git merge --no-ff. I tend not to.

So in summary, only use PRs when you need discussion. Otherwise just merge directly.

  • 1
    It's also worth mentioning that the discussion and feedback on a pull request can come from automated sources as well as team members. If you have a CI server set up, it can give build and test results so you never merge something that breaks the build on master. – Eric Oct 4 '18 at 18:07

Your Answer

