Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Fetch the branch and latest master locally before reviewing a PR
Before reviewing any pull request, branch, or commit, fetch the target branch AND the latest master locally, then diff the branch against master (three-dot) to review the complete change set in the context of the current codebase. Never review only the raw PR patch: without the master baseline you cannot see how the branch diverges from live master, whether the branch is stale/behind, or what the surrounding code looks like now — which is exactly what tells you whether the change is correct and whether it could have been done better. Prefer diffing origin/master...origin/<branch> over switching the working tree, so the reviewer's own checked-out branch is left untouched.
Bad example
| 1 | # Reviewing straight off the raw PR patch, no local fetch, no master baseline |
| 2 | gh pr diff 4608 |
| 3 | # -> you see only the patch hunks: not how the branch sits against current master, |
| 4 | # not whether it's behind master, not the real surrounding code |
Explanation (EN)
Reviewing only the raw PR patch hides how the branch diverges from the live master, whether it is stale/behind, and the true surrounding context — so regressions and 'could this be done better against the current code' judgements are missed.
Objašnjenje (HR)
Good example
| 1 | # Always pull the branch + latest master locally first, then compare branch vs master |
| 2 | git fetch origin master fix/FCK-3330-personer-edit-modal |
| 3 | git diff origin/master...origin/fix/FCK-3330-personer-edit-modal # full change set vs master |
| 4 | git log --oneline origin/master..origin/fix/FCK-3330-personer-edit-modal # commits on the branch |
| 5 | # now review the branch in the context of the current master |
Explanation (EN)
Fetch the target branch and the latest master, then review the three-dot diff of branch vs master. The complete change set is visible in the context of the current codebase, staleness is caught, and you can judge whether the approach could be improved.
Objašnjenje (HR)
Notes (EN)
Applies to every PR/branch/commit review. Use the three-dot diff (branch vs its merge-base with master) to see exactly what the branch adds; also check origin/master..branch commits and whether the branch is behind master. Fetch is read-only on the remote, and diffing origin/master...origin/<branch> avoids switching the reviewer's working tree. On company repos this stays read-only: fetch and diff only, never commit/push/merge.