We had a discussion in rOpenSci Slack recently. Here is the summary:
I got a pull request to one of the R packages I maintain on GitHub the other day. First of all, awesome! Getting PRs is great. Second, the PR was coming from the master branch on their fork. This made me wonder if it would make sense in a pull request template to ask the pull requester to make their changes on a feature branch.
There’s a few different questions in there:
- Is “feature branch” the best term to use?
- Is it a good idea to request this workflow?
The question garnered a lot of conversation. Here’s a summary of the conversation:
For what to call the branch, in addition to “feature branch” there was:
- new branch
- named branch
- fix branch
Consensus i think was that “new branch” might be better terminology than “feature branch”; not every PR is a “feature” per se, so “new” is more encompassing of all types of PRs. I still like “feature branch” myself because it seems this is the most widely used variety, but I think I’d parenthetically explain what it is.
Below, I’ll use “feature branch” for simplicity.
As for what to name each feature branch, there’s no hard and fast rule that I’m aware of. This discussion has some ideas though.
There was some concern that if you request that folks use a feature branch it might raise the barrier to contribution: if they haven’t heard of feature branches they may throw their hands up and walk away. Is this likely to happen? Anyone have thoughts?
Jenny Bryan posed a question on twitter: maybe GitHub could allow the repo maintainer to disallow PRs from a master branch. I’m in support of this
Some entirely get rid of their master branch, or at least don’t work on the master branch.
There was a fair amount of consensus, I think (correct me if I’m wrong), that it’s ideal if PRs do not come from the users master branch, but from a feature branch. Most agreed that asking users submitting a PR to use a feature branch is a good idea: if they haven’t heard of it, they’d be introduced to the concept; it’s good idea to not work on master if you are working on a fork that is meant to contribute back to the original repo; we agreed that it’s good practice to work on feature branches, so introducing people to the concept is a win.
Here’s a scenario to demonstrate:
- Fork a repo, and pull down localy (assuming the default branch is master)
- Make changes on the master branch
- Push up to GitHub
- Submit pull request
The above is fine. Trouble comes when any additional PRs are made by the same user. They might make changes on their local copy on master branch, and then try to pull in changes from upstream master, which will not end well. If the user uses feature branches for each pull request, then the workflow becomes easier:
- sync with upstream default branch
- make a feature branch
- do work on that feature branch
- push feature branch up to web
- submit PR
A few feature branch workflow info/help pages/slides:
- see also other Git workflows: https://www.atlassian.com/git/tutorials/comparing-workflows
- Joyce Robbins @jtr13 is working on slides for a talk in January: Git/GitHub Workflows
git pullis an antipattern? https://twitter.com/garybernhardt/status/1019272814019280897