Re:Of GitHub and Pull Requests (and comics)
by technoweenie on Wednesday April 11, 2012 @06:44PM
(#3830023)
This is closer to how we work at internally at GitHub. Everyone files pull requests for non trivial changes, and are responsible for merging and deploying them safely. Edit: This works because we all have push access of course.
This changes when you consider open source projects. Any change that is simple enough that I can scan and give my thumbs up, is likely one I can scan and click the merge button. Immediate Travis-CI results tell me everything is happy.
Anything where the merge button isn't sufficient is probably not something I'd like a stranger to push to my repository. If they're not a stranger, I'd seriously think about sharing collaboration access.
But hey, we're not necessarily done with Pull Requests. I have various ideas like this I'd like to explore at some point.
This, incidentally, is how code reviews work at Google. The reviewer (and owner, if you are submitting code to someone else's project) only check that the change looks good. The submitter is 100% responsible for ensuring that the change is good.
Once the reviewer says the change looks good, then the submitter gets permission in the source control system to actually submit the change. That's the feature I want from Github. I want to say "looks good, please merge" and then let them have access for one commit. (I believe gerrit works this way.) Then, the next tool I'd like is hosted unit tests and results on Github, so that the submitter can immediately see that they merged their change correctly and that the project is in a good state.
Oh well. It's probably time to go back to hosting my own repositories.