Chapter 5. But What About...
As mentioned in Chapter 1, full CTBD can be controversial. There are many questions and objections, so in this section I’m addressing the ones I hear most often.
How Can I Get My Code Reviewed Without Branches and Pull Requests?
Some people use branches to hold new code until their peers can review it and then merge the code back into the main branch. They often ask, “If you’re not using branches, how do you hold code back for review?”
The two main benefits of code reviews are that they allow teams to review code changes to verify quality and they give developers an opportunity to see one another’s code.
And then there are pull requests. In case the concept is unfamiliar, pull requests (PRs) are a feature of the Git version-control system that allows developers to alert one another when particular branches are ready for review. Many teams use PRs to implement and formalize their code reviews, with rules that no one can merge code into the main branch without first going through a PR. And when teams are distributed, particularly across multiple time zones, PRs are a convenient way to facilitate asynchronous code review.
But treat code reviews, and in particular PRs, with caution. They can introduce significant problems related to speed, quality, and trust—as discussed in the following sections.
Code Reviews Delay Integration
You could say that the need for code review is an argument in favor of branches, but I would rather turn this on its head and ...
Get What Is Trunk-Based Development? now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
