Pull Requests and Code Reviews

The usual flow

git switch -c fix/rounding-error
# edit, test and commit
git push -u origin fix/rounding-error

Then open the pull request in your hosting service (GitHub, GitLab, where it is called a merge request, or Azure DevOps). Teams often require approvals and passing automated checks before a merge. After the merge, delete the branch.

As the author

• Keep the PR small and focused on one purpose. Big PRs get shallow reviews.
• Write a description: what changed, why, how to test it, and a link to the ticket. Add screenshots for UI changes.
• Read your own diff first. Make sure the automated checks pass.
• Answer every comment. Push follow-up commits and say what you changed.
• Treat feedback as being about the code, not about you.

As a reviewer

• Start by understanding what the change is meant to do.
• Look at correctness, tests, readability, security and edge cases.
• Be specific and kind. Explain why, ask questions, and mark minor points as “nit”.
• Review promptly: a waiting PR blocks a colleague.
• Approve when the change is good enough, not when it is perfect.

Try it

Open a small PR in a practice repository and ask a colleague to review it. Then review a colleague’s PR and leave at least one useful comment.