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).
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 :-)
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):