Technology weblog

Monday Sep 04, 2017

Jez Humble's response on branching

I am currently writing a blog post on this topic. The short answer is this: 

* The best way to review code is through pair programming 
* It's a bad idea to gate merge to mainline - by creating a separate 
branch, for example - on a formal review process. This inhibits 
continuous integration (the best way of reducing the risk of bad 
changes, which is what you are really aiming to achieve). 
* I think Gerrit is a nice tool, but it should be used *after* check- 
in (that's how it's designed, in fact). Part of the job of the senior 
developers is to review all check-ins. They could, for example, 
subscribe to a feed. 

To summarize: code review is good. So good, we should be doing it 
continuously, through pair programming and reviewing commits. If a 
senior dev finds a bad commit, she should pair with the person who 
committed it to help them fix the problem. 

Gating merge to mainline on a formal review is bad, and creating 
branches to do so is extra bad, for the same reason that feature 
branches are bad. 




Post a Comment:
Comments are closed for this entry.

Hire us