Always do pull requests in branches

gitgithubpull requestsprocess Sat 10 January 2015

Until recently I've always done pull requests in the master branch, but after talking to various people I've learned that this isn't best practice. So I thought I'd share what I've learned so far. Feel free to learn me some more.

To keep things simple, always create a new branch when making some changes that you plan to submit as a pull request (PR). Having forked and cloned a repo, as outlined in Sawyer's guide to making a Pull Request, create a branch. Let's say you're going to fix some typos in the doc, then:

git checkout -b typofixes

This creates a branch called typofixes and moves you to it. If this PR is just going to contain a bunch of small typo corrections, you could do them in one commit. If you were going to make a number of different documentation improvements (eg the abstract, the SYNOPSIS, a SEE ALSO section, etc), then do a separate commit for each change. And add an entry into the Changes file as part of each commit.

Let's say that while working on your doc improvements you start thinking about some improvements to the interface. Do these changes in a different branch. Why?

The one case where it's arguably ok to do a PR from master is when you're making a small change and don't plan to do anything else to the module (for example marking a dist as deprecated). In reality though, when I start out thinking "this is a one-off", I often end up doing something else a bit later (e.g. as well as marking a module as deprecated, it's helpful to list other modules to use instead).

Thanks to ETHER, HAARG, and XSAWYERX for helping to educate me.

comments powered by Disqus