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 commits, 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 lets you create three different types of code reviews:
Post-commit Code Review. This code review can be used if your team workflow implies direct commits to the trunk (main) branch of the repository. You should commit and push a change to your Git repository before a review can be initiated.
Merge Request. If your team workflow 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.
File Review. You can create this code review to require changes to some specific files before these changes are actually made. Once this review is created the collaboration process is the same as with a regular post-commit code review.
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: Travis the Author and Andrea the Reviewer.
Travis has added a file to the repository and now wants Andrea to check if his code is okay.
Travis finds his commit in the commit list and creates a code review for it.
Next, Travis adds Andrea to the code review as a reviewer. As a result Travis's status is set to Waits for a response, meaning that he's waiting for a response from Andrea:
At the same time Andrea is sent a notification with a link to the review. Now it's her turn.
Andrea opens the review. Her current status is Reviewing the changes 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:
Andrea goes to the Changes tab and 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 Travis. Since she notices some issues, she writes a few comments, saving them as drafts, and clicks Submit drafts:
Once Andrea hits Submit drafts, the comments she saved get submitted, her status is set to Waits for a response and the turn goes back to Travis.
Now, Travis's status shows Revising the files because he's expected to respond and possibly make some improvements to his code. Travis replies to Andrea's comments, commits his fixes and attaches this commit to the review. To complete his turn he clicks Finish work:
The turn once again goes to Andrea as Travis's status changes to Waits for a response.
Andrea reviews the fixes. This time everything looks good, so she clicks Accept changes which also means that she completed the review:
It's Travis's turn again. He sees that Andrea has accepted the changes, and since there's nothing left for him to do, Space suggests that he closes the review:
If Andrea or Travis had marked all their discussions resolved, Space would have closed the review automatically after Andrea accepted the changes.