What? These statements and conclusions make no sense to me.<p><i>Code reviews mean that every time I want to integrate with master I&#x27;ve got to &#x27;grab a lock&#x27; and schedule and wait for a code review.</i><p>You&#x27;re using a terrible code review system. You should be able to have multiple potential commits out for review at any given time. You should also have multiple pending commits from your coworkers on your queue at any given time. The code review process is asyncrhonous: process them at your leisure (though sooner is better than later, for obvious reasons). Once the review has been approved, it can be rebased onto or merged into master. If the patches you&#x27;re writing are so far-flung that they don&#x27;t apply cleanly, break them into smaller pieces.<p><i>What typically happens in these code review cultures is you tend to make monolithic commits (to minimize the # of code reviews you have to do) and you also tend to minimize diffs with the code base (to make the CR easier for the reviewer).</i><p>These two statements are contradictory. Monolithic commits by definition increase the diff with the codebase, not decrease it. What you tend to see are <i>meaningful</i> commits: commits which do one specific thing, and fully test it, without breaking any other systems.