New version of an old rant. The GitHub pull request model makes sense if you plan to submit one giant PR a week. It’s terrible for rapid collaboration. Today I wanted to submit a 5 line patch to openaddresses/machine, in the branch ditch-node. I already have a fork NelsonMinar/machine. I had to:
- Switch to master branch in my clone of NelsonMinar/machine
- In my clone, manually set up an upstream remote for master
- Pull changes from upstream merge them with a fast forard.
- Push the merge result back to GitHub
- Repeat steps 1-4 manually for the ditch-node branch. I guess you’re expected to do this manually for every branch you care about.
- Create a new branch in my clone. I branched off the ditch-node branch
- Make my changes and commit them.
- Push my new branch back to GitHub with “–set-upstream origin”
- Use the GitHub UI to create a pull request.
- Fix the pull request so it’s a diff against ditch-node, not master. Note the branch I’m creating the PR in was branched off of ditch-node; no idea why GitHub didn’t respect that.
- Submit the pull request. Never ever touch that branch again until it’s accepted.
- As a bonus, the project maintainer warns me he has to rebase my pull request so it’s going to break my fork until I update.
It’s too much work on GitHub to follow along some repo and make occasional friendly improvements to it. I could use some simplified workflow which is just “keep my forked repo updated at all times with upstream unless it would clobber some work I did”. I imagine I could write a script to do that.
Maybe GitHub expects frequent committers to have write access and not go through pull requests. I like the review and auditing of pull requests, though.