A change can pass its tests and still benefit from another developer’s attention. Code review gives the team a chance to examine a change, ask questions, share techniques, and accept responsibility for what enters the repository. A pull request holds the change for that review before it is merged. section 5.1 section 5.1.2
Make the review process useful without letting it stall delivery:
- Protect the main branch from direct commits. Require one approval and passing checks before a pull request can merge; administrators are an exception to the direct-commit restriction. section 5.1
- Keep changes small. Aim for no more than 300 lines, including tests, so reviewers can focus and changes can merge often. Treat the limit as guidance, not a rigid rule. section 5.1.1
- Discuss the code, not the developer. Ask questions, accept feedback, check that the change works, and move extended disagreements out of comment threads. section 5.1.2
- Make time for reviews each day. Code waiting for approval is work in progress, not value delivered to a customer; politely tell teammates when you are waiting. section 5.1.3
Split a large change
Rather than asking someone to inspect a 2,000-line change at once, break the task into roughly ten reviews of 200 lines. Each review gives the team a smaller opportunity to spot problems and merge useful work. section 5.1.1
Use the GitHub branch-protection setup as a guide when configuring the protected branch, required review, and passing checks. section 5.1
Keep improving the process with the team. Questions, refactoring challenges, or fresh approaches to unit tests can make repeated reviews more engaging. The operational goal is a steady flow of small, checked changes—and a team that learns from reviewing them. section 5.1.4 section 5.1.1
