The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
This is a brief competitive analysis for Code Review, focused on the user experience and feature set of our competitors. Each one starts with a summary, followed by the list of findings, with the most interesting highlighted. Tools are separated into two sections: mature and not mature.
A tool specific for reviewing code, everything about the experience is focused on that. The UI is quite dense. Merge requests are called “Changes”. It focuses on only one commit, where authors can upload patch sets (revisions). “Changes” have an overview page and to see the files one must click-through into a specific “diff mode”. The overview page acts as a summary and lists the activity in chronological order, with comments unthreaded. Three interesting features are the ability to review commit messages, show the git blame inline, and auto-add reviewers based on git blame.
The code review experience in Phabricator is similar to Gerrit’s. However, the whole review UI is one big scrollable page, instead of being sectioned into different views/pages. Three other notable differences are the support for both pre and post-merge reviews, showing older inline comments in updated diffs (ported/ghost comments), and showing test and coverage reports inline.
It’s the only code review tool we reviewed that attempts to port the IDE experience to a browser UI for code review, with a navigation sidebar to jump between sections and files, and a fixed content view. Like Phabricator, it supports pre and post-merge reviews but is more flexible about the review’s starting point: specific commits, whole branches, committed files, patch files, or attachments.
In general, its pull requests and review experience are very similar to GitHub.
Like Bitbucket, it largely follows the GitHub’s experience, but manages to give it more structure and add many more features. Of note are their consistent locations for actions and secondary information, granular types of approval, good approach to merge confirmation and actions, and the visibility of policies (items blocking the merge) and status of the pull request.
GitLab’s current code review experience is largely modeled after GitHub’s, with a discussion/activity view and a changes view with all of the files stacked vertically. Some relevant differences in GitHub are resolving whole discussions (instead of comments), the concept of reviewers, submitting a summary comment with the review, and viewing only the changes done since the user’s last review. Some of its frequently mentioned issues are the difficulty in finding who is responsible for looking at the code, the lack of inline test and coverage reports, and the lack of an audit trail.
Even though the UI is not the most appealing or modern, Review board has some interesting features that set it apart. Specifically, the ability to filter comments by type and author, and the personal dashboard that is organized like a “code review inbox”.
It has a fresh approach to navigating a code review, with its intuitive toolbar that allows cycling between files, discussions, and drafts, and also a visual way to change which revisions are compared. There’s a big focus on the reviewer experience, especially when re-reviewing changes, by highlighting what files and discussions they need to review again or reply to. The status of the pull request is given visually with a small circular chart that shows the passed/failed checks. Other highlights include the ability to track of who reviewed which revision of each file, automatically entering single file mode to preserve performance, and setting merge options and commit message before merging.