Before which process is code review performed when version control is used?

In modern version control workflows, such as GitFlow or feature branching, code review is a crucial quality assurance step. A developer typically works on a new feature or bug fix in a separate branch. Once the work is complete and committed to that branch, they initiate a "pull request" or "merge request." This action formally proposes that their changes be integrated (merged) into a main branch (e.g., main, develop). The code review process is conducted on this pull/merge request before the final merge is approved and executed, ensuring that code quality and standards are met before impacting the primary codebase.

A. Branching code: Branching is the act of creating a new line of development. Code is written after a branch is created, so a review cannot happen before this step.

C. Checkout of code: A checkout operation retrieves a specific version of the code to the local machine for development or inspection. It precedes the writing of new code.

D. Committing code: Committing saves changes to the developer's local or feature branch. While developers may self-review before committing, the formal peer review process occurs after commits are pushed and before they are merged.

1. GitHub Docs, "About pull requests": "Pull requests are a feature that makes it easier for developers to collaborate... Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch." This document explicitly places the review process between the initial commits and the final merge.

2. Atlassian, "Git Tutorial - Making a pull request": "Pull requests are a mechanism for a developer to notify team members that they have completed a feature. Once their feature branch is ready, the developer files a pull request... This lets everybody involved know that they need to review the code and merge it into the main branch." This official vendor documentation confirms the review happens before the merge.

3. Chacon, S., & Straub, B. (2014). Pro Git (2nd ed.). Apress. In Chapter 5.2, "Contributing to a Project," the workflow described for accepting contributions involves fetching a contributor's work into a topic branch and then reviewing it. "You can merge it into your master branch... But first, you’ll probably want to verify the code." This canonical text on Git places verification/review before the merge.