Do you enable pull requests to ensure code is reviewed?
Last updated by Brady Stroud [SSW] 10 months ago.See historyEverybody strives to be perfect, but mistakes are normal, and it is easy for a developer to skim over errors when they've read their own code code hundreds of times!
Pull requests are the best way to ensure that two sets of eyes see every change - so the responsibility is never solely on the person writing the code.
When Pull Requests are enabled, developers must create a branch and make their changes on that branch. Then they submit a Pull Request to merge their changes back into main. Each pull request must be approved by another reviewer.
Useful resources - learn about Pull Requests
Video: What is a Pull Request? (3 min)
- Do you know how to make content changes on GitHub?
- Do you use Pull Request templates to specify the expectations and requirements for each PR?
- Pull Request - Do you do over the shoulder reviews?
- Do you avoid Merge Debt?
- Do you know how to write a great Pull Request (PR)?
- Do you know to not 'Push' your Pull Requests? (aka discuss then build)
- Do you know when to add your changes to an existing PR?
- Do you include a useful description of your changes?
- Do you save failed experiments in abandoned pull requests?
- Do you know when you use @ mentions in a PBI?
- Do you avoid linking issues to PRs in GitHub?
- Do you merge open source pull requests using the "Squash and merge" option?
- Do you have a standard set of pull request workflows?
- Do you still review Pull Requests when you are not a required viewer?
- Do you use Co-Creation Patterns?
- Do you have a page owner for each webpage?
- Do you know how to make content changes on GitHub?
- Do you use Pull Request templates to specify the expectations and requirements for each PR?
- Pull Request - Do you do over the shoulder reviews?
- Do you avoid Merge Debt?
- Do you know how to write a great Pull Request (PR)?
- Do you know to not 'Push' your Pull Requests? (aka discuss then build)
- Do you know when to add your changes to an existing PR?
- Do you include a useful description of your changes?
- Do you save failed experiments in abandoned pull requests?
- Do you know when you use @ mentions in a PBI?
- Do you avoid linking issues to PRs in GitHub?
- Do you merge open source pull requests using the "Squash and merge" option?
- Do you have a standard set of pull request workflows?
- Do you still review Pull Requests when you are not a required viewer?
- Do you use Co-Creation Patterns?
- Do you have a page owner for each webpage?