JetBrains Space Help

Review Code

Space makes it easy for you and your team to review code, discuss changes, and keep track of accumulated knowledge.

A code review in Space can be associated with one or more revisions, or an entire branch. Once initiated, a code review becomes a separate entity with a unique ID, allowing you and your teammates to exchange comments over specific lines of code or discuss changes in general.

Space supports post-commit reviews, which means you should commit and push a change to your Git repository before a review can be initiated.

If your organization requires that code is reviewed before it gets merged into the base (main, master) branch, you can commit to your feature branch and create a special review for this commit called Merge request. As soon as this review is successfully passed, you can then merge your branch into the base branch right from Space.

Why review code?

There can be many reasons for a team to review code, and here are just a few of them:

  • You have committed a change and now you want your fellow teammates to examine it and help you make sure that the new code is clear, readable and doesn't contain any serious flaws.

  • You have stumbled upon a potential problem in your teammate's change and you want to draw their attention to it.

  • You've been working on your feature branch and now you want your code reviewed and approved before merging it to the base branch (main, master).

  • You want to keep some of your teammates updated of your project status whenever an important change is made.

Turn-based code review

In Space, a typical code review process involves two or more participants which can be divided into the following roles:

  • Author is a committer who usually requests (creates) a review for his/her revision and invites one or more reviewers to examine the changes he/she has committed.

    The commit author is always considered the author of the review, no matter who actually creates the review.

  • Reviewer is expected to examine the changes committed by the author. Participants can discuss specific lines of code, or add general comments. As soon as all the issues are resolved, the reviewer approves the changes.

Space code review process resembles a strategy game where participants take turns when playing. Space lets you know when it's your turn to act or wait for the other participant(s) to finish what they are doing. Status indicators for each of the participants reflect whose turn it is at any moment.

Code review example

Let's take a look at a typical code review with two participants: Walter the Author and Susan the Reviewer.

Walter has added a file to the repository and now wants Susan to check if his code is okay.

  1. Walter finds his commit in the commit list and creates a code review for it.

  2. Next, Walter adds Susan to the code review as a reviewer. As a result Walter's status is set to Waiting, meaning that he's waiting for a response from Susan:


    At the same time Susan is sent a notification with a link to the review. Now it's her turn.

  3. Susan opens the review. Her current status is Reviewing because that's what she is expected to do:


    If she goes to the review list, she will notice that a new item with the Needs my review status has been added to it:

  4. Susan examines the code. At this stage Space gives her a choice of either accepting the changes if everything is fine, or start a discussion and wait for response from Walter. Since she notices some issues, she writes a few comments, saving them as drafts, and clicks Finish → Wait for response:


    Once Susan hits Wait for response the comments she saved get submitted, her status is set to Waiting and the turn goes back to Walter.

  5. Now, Walter's status shows Revising because he's expected to respond and possibly make some improvements to his code. Walter replies to Susan's comments, commits his fixes and attaches this commit to the review. To complete his turn he clicks Update review:


    The turn once again goes to Susan as Walter's status changes to Waiting.

  6. Susan reviews the fixes. This time everything looks good, so she clicks Accept changes which also means that she completed the review.

  7. It's Walter's turn again. He sees that Susan has accepted the changes, and since there's nothing left for him to do, Space suggests that he closes the review:


    If Susan or Walter had marked all their discussions resolved, Space would have closed the review automatically after Susan accepted the changes.

Last modified: 02 June 2022