Until recently I've always done pull requests in the
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?
git commit --amendwhen you realise you forgot to update
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).comments powered by Disqus