[cmwelsh]

My employer is similar but a little stricter about how we use GitHub pull requests. All new code goes in via pull request. All pull requests are reviewed by another developer. Almost all pull requests are sent to QA to test acceptance criteria.

The sneaky commit will get you many frowny faces on chat.

It works rather well. Does anyone else work like this?

[Cyranix]

We're not on GitHub (to my dismay) but my company does use Atlassian Stash, and they've been mimicking GitHub more and more with each update.

Our development process does include pull requests, and code review is mandatory (with the number of reviewers configurable at some level), as is a successful build from Jenkins. Stash's UI will not permit a merge operation without satisfying those criteria. There's also a restriction on the master branch so the sneaky commit isn't even possible.

[wizard_2]

My team works like this with a twist. You merge your own pull request. You have developers, designers, pm's, etc to help review the change. You use them if you need them and you take responsibility for your bugs. We'll drop everything to review someone else's pull, and in turn that happens for your own pulls.

[cmwelsh]

We also merge our own pull requests but there is less concept of code ownership. Bugs can be fixed by anyone who grabs them and assigns them to themselves. Blame may point out the cause and you can send the author a friendly message on Skype so they are aware of your fix. Perhaps they can even mark your fix as peer reviewed while they're at it.

[bigsassy]

We do the same thing, almost word for word. And yes, it has worked very well for us too.

[icedchai]

curious. what industry are you in?

[cmwelsh]

Web development consulting. We are the development team behind multiple funded startups - mercenaries for hire.