|
| 1 | +# Reviewing a Pull Request |
| 2 | + |
| 3 | +This guide explains the day-to-day steps for **reviewing** a PR on GitHub, using both Git and the GitHub CLI (`gh`). It assumes you have already completed the one-time setup from the main [workflow guide](./github.md). |
| 4 | + |
| 5 | +--- |
| 6 | + |
| 7 | +## 1. Prerequisites |
| 8 | + |
| 9 | +You should already have: |
| 10 | + |
| 11 | +- A local clone of the forked repository, with `origin` pointing to your fork and `upstream` pointing to the canonical repo. |
| 12 | +- The GitHub CLI (`gh`) installed and authenticated. |
| 13 | +- Your `main` branch up to date with upstream: |
| 14 | + |
| 15 | +```bash |
| 16 | + git fetch upstream |
| 17 | + git switch main |
| 18 | + git merge --ff-only upstream/main |
| 19 | +``` |
| 20 | + |
| 21 | +--- |
| 22 | + |
| 23 | +## 2. Fetching & Checking Out the PR |
| 24 | + |
| 25 | +### 2.1 Using GitHub CLI |
| 26 | + |
| 27 | +```bash |
| 28 | +gh pr checkout <PR-number> |
| 29 | +``` |
| 30 | + |
| 31 | +> This automatically fetches the PR and switches to a branch named `pr-<PR-number>`. |
| 32 | +
|
| 33 | +### 2.2 Using Plain Git |
| 34 | + |
| 35 | +```bash |
| 36 | +git fetch upstream pull/<PR-number>/head:pr-<PR-number> |
| 37 | +git switch pr-<PR-number> |
| 38 | +``` |
| 39 | + |
| 40 | +--- |
| 41 | + |
| 42 | +## 3. Smoke-Testing the Changes |
| 43 | + |
| 44 | +Before you read code or leave comments, **always** verify the PR builds and tests cleanly. |
| 45 | + |
| 46 | +### 3.1 Local Build |
| 47 | + |
| 48 | +```bash |
| 49 | +make venv install install-dev serve # Install into a fresh venv, and test it runs locally |
| 50 | +``` |
| 51 | + |
| 52 | +### 3.2 Container Build (if applicable) |
| 53 | + |
| 54 | +```bash |
| 55 | +make docker-prod # Build a new image |
| 56 | +make compose-up # spins up the Docker Compose stack |
| 57 | +``` |
| 58 | + |
| 59 | +### 3.3 Automated Tests |
| 60 | + |
| 61 | +```bash |
| 62 | +make test # or `pytest`, `npm test`, etc. |
| 63 | +``` |
| 64 | + |
| 65 | +### 3.4 Lint & Static Analysis |
| 66 | + |
| 67 | +```bash |
| 68 | +make lint # runs ruff, mypy, black --check, eslint, etc. |
| 69 | +``` |
| 70 | + |
| 71 | +> **If any step fails**, request changes and paste the relevant error logs. |
| 72 | +
|
| 73 | +--- |
| 74 | + |
| 75 | +## 4. Functional & Code Review Checklist |
| 76 | + |
| 77 | +Use this checklist as you browse the changes: |
| 78 | + |
| 79 | +| Check | Why it matters | |
| 80 | +| --------------------------------- | -------------------------------------------------- | |
| 81 | +| **Does it build locally?** | Ensures no missing dependencies or compile errors. | |
| 82 | +| **Does it build in Docker?** | Catches environment-specific issues. | |
| 83 | +| **Tests are green?** | Guards against regressions. | |
| 84 | +| **No new lint errors?** | Maintains code quality and consistency. | |
| 85 | +| **Commits are clean & signed?** | One-commit history & DCO compliance. | |
| 86 | +| **Code follows style guidelines** | Consistency in formatting, naming, and patterns. | |
| 87 | +| **Security checks passed** | No secrets leaked, inputs validated, etc. | |
| 88 | +| **Docs / comments updated?** | Documentation stays in sync with code. | |
| 89 | +| **Edge cases & error handling** | Robustness against invalid inputs or failures. | |
| 90 | + |
| 91 | +--- |
| 92 | + |
| 93 | +## 5. Leaving Feedback |
| 94 | + |
| 95 | +### 5.1 Inline Comments |
| 96 | + |
| 97 | +Use `gh pr review` to leave comments: |
| 98 | + |
| 99 | +```bash |
| 100 | +# To comment without approving |
| 101 | +gh pr review --comment --body "Nit: rename this variable for clarity." |
| 102 | + |
| 103 | +# To request changes |
| 104 | +gh pr review --request-changes --body "Tests are failing on CI, please fix." |
| 105 | + |
| 106 | +# To approve |
| 107 | +gh pr review --approve --body "Looks good to me!" |
| 108 | +``` |
| 109 | + |
| 110 | +### 5.2 Approving in the UI |
| 111 | + |
| 112 | +1. On the PR page, click **"Files changed"**. |
| 113 | +2. Hover over a line and click the **+** to leave an inline comment. |
| 114 | +3. After addressing all comments, click **Review changes** → **Approve**. |
| 115 | + |
| 116 | +--- |
| 117 | + |
| 118 | +## 6. Merging the PR (as a Maintainer) |
| 119 | + |
| 120 | +> Only merge once all approvals, status checks, and CI jobs are green. |
| 121 | +
|
| 122 | +1. On GitHub, click **Merge pull request**. |
| 123 | +2. Choose **Squash and merge** (default) or **Rebase and merge**. |
| 124 | +3. Verify the commit title and body follow [Conventional Commits](https://www.conventionalcommits.org/). |
| 125 | +4. Confirm the **Signed-off-by** trailer is present. |
| 126 | +5. Click **Confirm merge**. |
| 127 | + |
| 128 | +GitHub will delete the `pr-<number>` branch automatically. |
| 129 | + |
| 130 | +--- |
| 131 | + |
| 132 | +## 7. Cleaning Up Locally |
| 133 | + |
| 134 | +```bash |
| 135 | +git switch main |
| 136 | +git fetch -p # prune deleted remotes |
| 137 | +git branch -D pr-<PR-number> |
| 138 | +``` |
| 139 | + |
| 140 | +--- |
0 commit comments