Pull Requests
A pull request, also known as a “PR”, is a way to suggest combining changes from one branch into another. It allows you to collaborate with others by reviewing and discussing the proposed updates before they’re added to the main codebase.
The testing and quality industry is constantly evolving. The trend over the years has been for product practices to move away from a siloed testing existence, and towards one that is more integrated with the rest of the business. As part of this it is essential that we find ways to stay on top of code and product changes. Pull requests are one such way to do this.
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:
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.
Localization testing with confidence Combine a global network with flexible testing tools to see what your website looks like to customers around the world
Explore MoT
Tue, 6 May
The Future of Testing in an Automated World: Embracing Continuous Learning and A
Boost your career in software testing with the MoT Software Testing Essentials Certificate. Learn essential skills, from basic testing techniques to advanced risk analysis, crafted by industry experts. Early access available now at a discounted rate!
A one-day educational experience to help business lead with expanding quality engineering and testing practices.
Debrief the week in Testing via a community radio show hosted by Simon Tomes and members of the community