42

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.

Improve this question
6
  • 2
    What exactly do you feel is lacking from those answers?
    – RubberDuck
    Dec 12, 2015 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, 2015 at 17:11
  • 2
    I am looking at this from a Best Practices or How to maintain a good git history point of view.
    – Ashhar Hasan
    Dec 12, 2015 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, 2015 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, 2015 at 17:18

2 Answers 2

Reset to default
40

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.

Improve this answer
2
  • 5
    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, 2015 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, 2018 at 3:09
11

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.

Improve this answer
1
  • 4
    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, 2018 at 18:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.