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

In modern version control workflows, such as GitFlow or GitHub Flow, code review is a crucial quality gate. 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 presents the code changes for review by peers. The review process, including discussion and potential revisions, must be completed and approved before the code is integrated (merged) into the main or target branch (e.g., main, develop).

A. committing code: Commits are frequent, local saves of progress. Reviewing before every commit is impractical and not a standard workflow.
B. branching code: Branching occurs before new code is written, so there is no new code to review at this stage.
D. checkout of code: Checkout is the act of switching between branches. It is an independent action and not a trigger for code review.

1. GitHub Docs, "About pull requests": "Pull requests let you tell others about changes you've pushed to a branch in a repository... 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 before the merge.

2. Atlassian, "Git Tutorial - Comparing Workflows": In the description of the Gitflow Workflow, it states, "When a developer is ready to start work on a feature, they create a feature branch... When the feature is complete, the developer files a pull request to merge their feature branch into the develop branch." The pull request is the mechanism for code review, which precedes the merge.

3. Google Engineering Practices Documentation, "The Standard Code Review Workflow": This document outlines the standard process: "1. A developer creates a change... 2. The developer creates one or more CLs [changelists] and uploads them to the code review tool. 3. The developer sends the CLs for code review... 4. The reviewer submits their comments... 5. The developer addresses all the reviewer's comments... 6. Once a reviewer is satisfied... they approve the CL... 7. After the CL is approved... the developer submits the CL to the codebase." The submission step is equivalent to a merge.