Using github pull requests inside a company¶

Tags: django, nelenschuurmans

A couple of months ago I read an article about effective pull requests for teams. The article made me want to use pull requests inside our company (Nelen & Schuurmans), too.

I myself only started using pull requests a lot a few weeks ago, when writing pull requests for zc.buildout. Make a branch, work on a feature, push the branch, open a pull request. The good thing about a pull request on github is that you can easily give feedback.

Me and a few others started working with pull requests at our company. We decided to just start doing it “as it is good to do it”. There’s no sense in having meetings to tell everyone to do it: it has to grow into the team’s common work process.

So… yesterday, for example:

• I cooked up a small fix on a branch and pushed it to github.

• I created a pull request out of it on github.

• I went to a colleague’s desk and asked him to quickly review it now (as I really needed it quickly).

• I got a comment (“no hardcoded admin url, use a reverse admin url”). Yep, I normally omit that step. Good to get feedback to force me to behave myself!

• Did the django admin reverse thingy, pushed to the branch again, told my colleague.

• Got the pull request accepted and released a new version of the software.

Good thing about github: if you include "fixes #18"-like comments in your commit message, the related issue is closed automatically. But not if you don’t push to the master branch. If you push to a branch, the issue stays open. But once the pull request with your branch gets accepted, the issues also get closed. Nice!

Some closing comments on github pull requests inside our company:

• It already looks like it can really improve our quality.

• You learn as reviewer.

• You learn as branch-pusher.

• We really should need to find a better way to do reviews: I normally want them Right Now. That’s pretty invasive :-)