When a code change, typically in a feature branch authored by a developer, is proposed for merge to the main or master branch, the set  of proposed changes are called a pull request(in GitHub) or a merge request (in GitLab). The specific changes proposed in the pull request are also usually described in a note accompanying the PR, to assist in code review.The pull request exists as an artefact in the code management software and would usually have safeguards associated with it such as an approval process so that at least 1 person, other than the author of the PR, has reviewed and/or tested the new code. Approval of the pull request allows the code change to be merged to main or master. The evolution towards trunk-based development has meant that both development and testing is executed on the code change while it still in the branch, before merge to master, that is to say, when the pull request is active and not yet approved.A couple of advantage of this approach of testing and controlling the code, that moves towards production, at the pull request stage: Bugs found on the PR/branch during testing can be fixed on the branch before merge. This is typically faster than finding bug on master/main/release branch and then pushing a fix through to main or master for retest. Bugs that are found on the PR/branch do not contaminate main. This approach reduces the rate of introduction of bugs to main and subsequent disruption for other developers.