MRs and PRs from IntelliJ
Intermediate IntelliJ UI
Why this matters
Reviewing in the IDE gives you what a web diff cannot: the rest of the file, the rest of the project, and the ability to run what you are reviewing. For instructions and documentation, that is the difference between spotting typos and spotting mistakes.
The tool windows
With an account connected (lesson 16.2):
| Platform | Window |
|---|---|
| GitHub | Pull Requests |
| GitLab | Merge Requests |
Both list what is open, filtered by author, assignee, reviewer or label, and open a selected one as a tab with its description, changed files, timeline and checks.
Creating one
- Commit and push your branch (⇧⌘K).
- In the tool window, use Create Pull Request or Create Merge Request.
- Fill in the title and description; IntelliJ pre-fills from your commits and any template in the repository.
- Choose reviewers, labels and the target branch.
- Create, and mark it a draft if it is not ready.
The description is the part that matters: what, why, how to check, and the closing keyword (lesson 9.7).
Reviewing
Opening one gives you the description, the file list and the conversation. Two ways to read the change, and the second is the reason to be here:
- The diff, in IntelliJ's diff viewer, which is the best of the three tools in this course for a large change.
- Check out the branch from the tool window, and read the real files with everything else in place.
Comments attach to lines: click the gutter in the diff, write, and submit. Reviews can be submitted as Comment, Approve, or, on GitHub, Request changes. Threads from the platform appear inline and can be replied to and resolved.
For documentation work, the check-out route is the one to use. Following a set of instructions is a review nobody else reliably does (lesson 13.7).
Checks and pipelines
The tool window shows each check or job with its status, and links to the log. A failing check opens in a browser, which is the right place for a long log (lesson 14.3).
What still belongs in the browser
| Case | Why |
|---|---|
| The merge box | The authoritative list of unmet requirements and the merge options |
| Approval rules, CODEOWNERS, protected branches | Read them where they are configured |
| Long CI logs | Better search and sharing |
A reasonable habit, the same as for VS Code: review in the IDE, merge in the browser.
How to do it
$ git fetch
$ git switch docs/12-windows-install-stepsOr with the platform tools, gh pr checkout 42 and glab mr checkout 42. Checking out the branch is the highest-value review action available to a writer.
The equivalent extensions do the same job, with a lighter diff viewer. See lesson 15.8.
- Pull Requests or Merge Requests tool window
- Create Pull Request / Create Merge Request
- The tool window's checkout action for the branch
- Find Action (⇧⌘A) → "Pull Requests", "Merge Requests"
Everything is on the merge request page too, and the page is authoritative for the merge box and approval rules (lesson 9.8).
The same for pull requests (lesson 10.8).
Common mistakes
- Reviewing only the diff when the change is a set of instructions.
- Leaving comments one at a time instead of one review.
- Approving without saying what you checked.
- Forgetting to switch back to your own branch afterwards.
- Expecting the tool window to show every merge requirement. The merge box on the web is authoritative.
Try it yourself
Goal: review a change from inside the IDE.
- Connect your platform account and open the Pull Requests or Merge Requests tool window.
- Create a merge request from a branch with one commit, writing a real description.
- Open it, and use the tool window to check out its branch.
- Leave one line comment and submit the review as Comment.
- Open the same merge request in the browser and note what the page shows that the IDE does not.
Expected result: one merge request created and reviewed from the IDE, and a clear idea of which half of the job belongs in the browser.
Show solution
Step 3 is the habit worth keeping. A diff shows changed lines; a checkout shows the change in context, running, with everything around it. For instructions, documentation and error messages, that is where the real review findings come from.