MRs and PRs from VS Code

Why this matters

Reviewing in the editor has one real advantage over the browser: you see the rest of the file. Web diffs show a few lines around each change, which is enough to spot a typo and not enough to notice that the paragraph now contradicts the one above it.

The two extensions

Both add a view to the Activity Bar listing what is open, assigned to you, and waiting for your review.

Creating one

From a branch you have pushed:

1. Push the branch, or click Publish Branch.
2. Open the extension's view and choose Create Pull Request or Create merge request.
3. Fill in the title and description, which the extension pre-fills from your commits and any template in the repository.
4. Add reviewers, and mark it a draft if the work is unfinished.
5. Create. The extension opens the new merge or pull request as a tab.

The description matters as much here as anywhere: what, why, how to check, and Closes #12 (lesson 9.7). The editor's box is a real editor, which makes writing a proper description easier than in a browser textarea.

Reviewing one

Opening a merge or pull request from the list gives you a description tab, the list of changed files, and the conversation. Two ways to read the change:

• The diff, as in the browser, but in an editor tab.
• Check out the branch: the extension offers this, and then you are reading the real files, with everything else in place. That is the mode worth using for documentation.

Comments work on lines: click the gutter, write, and choose whether to add it now or hold it in a batch. Submitting the review takes the verdict: Comment, Approve, or, on GitHub, Request changes (lesson 10.8).

Suggestions can be written by hand in the comment box using a suggestion fence, which the author then applies with one click on the platform (lesson 9.8).

Pipelines and checks

Both extensions show the pipeline or check status for the current branch in the Status Bar, and list the jobs on the merge or pull request tab. A failing job links to its log, which opens in a tab where the search box is better than a browser's (lesson 14.3).

When the browser is still better

Two cases, and it is worth knowing them rather than fighting the tool:

A reasonable habit: review in the editor, merge in the browser.

How to do it

$ gh pr list          # GitHub
$ gh pr checkout 42
$ glab mr list        # GitLab
$ glab mr checkout 42

Common mistakes

• Reviewing only the diff when the change is a set of instructions. Check out the branch and follow them.
• Leaving comments as individual notes instead of batching them into one review.
• Approving from the editor without saying what you checked (lesson 13.7).
• Assuming the editor shows every merge requirement. The merge box on the web is authoritative.
• Forgetting to switch back to your own branch after checking one out.