JetBrains Space and Code Review Integration Directly in PhpStorm

1. Why Code Review Belongs in the Editor, Not the Browser

A typical browser based code review flow looks like this: a comment on a specific line gets read, the developer switches back to the IDE, finds the affected spot, rebuilds the context, switches back to the browser and types a reply. Each of these switches interrupts the flow of thought and costs time that adds up quickly across several comments per merge request.

PhpStorm integrates merge request workflows from JetBrains Space, GitLab and GitHub directly into the IDE. Comments appear as an annotation next to the affected line of code, context is immediately visible, and replies can be written without switching tabs. This not only reduces the time per review but also the error rate, since the developer sees the current code while replying rather than a possibly outdated diff in the browser.

2. Overview of the Available Integrations

PhpStorm offers three relevant paths for code review integration: the native JetBrains Space plugin for teams using Space as a git host and project management platform, the built-in GitLab integration for GitLab based merge requests, and the GitHub Pull Requests feature for GitHub repositories. All three follow a similar basic principle but differ in operational details and feature scope.

For Magento projects, which are frequently hosted on GitLab, the GitLab integration is usually the most relevant. JetBrains Space suits teams that want to combine code review with issue tracking and CI/CD on the same platform. Which integration gets used therefore depends less on PhpStorm itself than on the git hosting already in use, PhpStorm adapts to the existing setup rather than forcing its own platform.

3. Setup: Connecting Accounts and Authorizing Access

For GitLab and GitHub, setup happens under Settings, Version Control, Git, and additionally under Settings, Version Control, GitLab or GitHub respectively. There, authorization happens either via OAuth in the browser or by entering a personal access token with the scopes for repository and merge request access. For JetBrains Space, sign in happens through the Space tool window with a direct login to the Space organization.

When issuing a token, it is important to enable only the scopes actually needed. For pure code review, read and write access on merge requests plus read access on the repository is usually enough, while administrative scopes like deleting repositories or changing project settings are not needed and should be left out for security reasons.

Settings > Version Control > GitLab
  Server URL: https://gitlab.example.com
  Token scopes: api (for merge requests), read_repository
  Test: "Connection successful" must appear

4. The Merge Request Tool Window at a Glance

After a successful connection, a dedicated tool window appears, reachable via View, Tool Windows, Merge Requests or Pull Requests depending on the platform. It lists all open merge requests for the current repository, filterable by your own requests, assigned reviews, or all open requests in the project. Clicking an entry opens the full diff view inside the IDE.

The diff view uses the same diff viewer PhpStorm uses for local git comparisons, including syntax highlighting and the ability to navigate directly within the diff. Unlike in the browser, full code intelligence remains available: jump to definitions, quick documentation and inspections all work inside the review view too, which is naturally not possible in the browser.

5. Reading and Replying to Comments Directly in the Editor

Existing comments from a merge request appear as a gutter icon next to the affected line, both in the diff viewer and, depending on configuration, directly in the normal editor when viewing the current branch. Clicking the icon opens the full comment timeline with all previous replies, so the entire discussion history can be followed without switching context.

Replies are written directly in this popup and synced with GitLab, GitHub or Space via the platform API. A comment can additionally be marked as resolved once the underlying question is settled, which has the same effect as resolving in the browser interface and is reflected there as well, since both sides use the same underlying API.

6. The Real Workflow Advantage: Context Stays Intact

The biggest advantage shows up not with single comments but when fixing several notes in one session. Since the code is directly visible in the editor, a flagged spot can be changed immediately, without first searching for the affected section in the browser and then finding it again in the IDE. After the change, a fixup commit can be created directly from the IDE and the comment marked as answered, in one continuous step.

This continuity reduces not only actual editing time but also cognitive load: a developer no longer has to remember which of ten browser comments have already been addressed while simultaneously navigating in the IDE. Instead, the list of open comments in the tool window can be worked through linearly from top to bottom, which noticeably lowers the error rate especially for large reviews.

Workflow for review feedback:
1. Merge Requests tool window -> open comment
2. Adjust code directly in the editor
3. Reply to comment + mark "Resolve"
4. Git: create commit "fixup: address review comment"
5. Push, without ever switching browser tabs

7. Creating Your Own Reviews and Suggested Changes

Not just replying, creating a review also works entirely from the IDE. In the diff viewer, clicking a line adds a new comment that is automatically attached to the corresponding line in the merge request upon saving. For GitLab and GitHub, PhpStorm also supports suggested changes, where a concrete code proposal is sent along as an acceptable diff.

This suggested changes feature is especially valuable for small, unambiguous fixes like typos or missing type declarations, since the author of the merge request can accept the suggestion with a single click without typing anything themselves. For larger structural comments, a plain text comment remains more sensible, since a direct code suggestion often falls short and crowds out the actual discussion about the approach.

8. Limits: What Still Happens in the Browser

As extensive as the integration is, not every task around merge requests can be done from PhpStorm. Pipeline configuration, managing branch protection rules, approval policies with multiple required reviewers, or viewing detailed CI logs typically remain tasks handled in the browser interface of GitLab, GitHub or Space, since PhpStorm deliberately stays focused on the code review part.

Complex, multi-threaded discussions with many participants and nested replies can be read in the compact IDE popup but feel clearer in the full browser interface. For fast, code-near communication during active development, the IDE integration still wins on speed, while the browser retains its place for an overview of the overall review status.

9. Practical Workflow and Comparison of the Integrations

A sensible starting point is enabling exactly one integration, matching the git host actually in use, rather than setting up all three preemptively. After the first connection, a test run on an existing merge request with a few comments is worthwhile to get familiar with the interplay of tool window, diff viewer and comment popup before the integration becomes the standard path in daily review work.

The table below compares the three integrations regarding feature scope and suitability for typical Magento team setups. It shows that all three solve the core problem of context switching, but differ in details like suggested changes and the depth of Space's own project management connection.

10. Summary

11. FAQ: Code Review in PhpStorm: The Key Facts at a Glance