How to - Handle Material Pull Request Merged w/o Review or Basic Review
How to - Handle Material Pull Request Merged w/o Review or with Basic Review
Why Is It a Problem?
Even the best developer makes mistakes and misses things. After coding for a period of time and self testing most coders become partially "numb" to issues in the code they just wrote and tested. The review process, putting a fresh "set of eyes" on code someone else wrote many times reveals issues that were accidently missed or forgotten by the code owner. Many times thorough review processes leading to critical quality fixes.
This is why skipping this process for Pull Requests that contains "untrivial" number of changes increases significantly the chances of missing problems and potential bugs and in general adding quality risk to the code base.
How to Handle?
In order to reduce the quality risk level that is introduced by Pull Requests merged w/o review you can can do one of the following actions:
Revert Pull Request
Git provides method to revert pull requests and get the base branch back to the state before the merge was done. This will remove the quality risk from the base branch, and pending branch is still available, will allow to open a new pull request and have a proper review process before this code is merged again.
Retroactively Review Changes
Even though this code was merged, It is possible to look and review the changes made in this branch. If there are issues that were found and needs to be fixed it is possible to open a new branch for all modifications and fixes that are required from the retroactive review.
Educate you team about the risks of this practice
When you come across one of these practices it is important to discuss this with your team member and explain the risks.