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.
|Content Last Reviewed
This direction is constantly evolving and everyone can contribute:
Code Review is an essential activity of software development. It ensures that contributions to a project maintain and improve code quality and security, and is an avenue of mentorship and feedback for engineers. It can also be one of the most time consuming activities in the software development process.
GitLab's guiding principle for Code Review is: Reviewing code is an activity that ultimately improves the resulting product, by improving the quality of the code while optimizing for the speed at which that code is delivered.
The Code Review process begins with authors proposing changes to an existing project via a change proposal. Once they've proposed the changes they need to request feedback from peers (Developers, Designers, Security and Operations Teams, Product Managers, etc) and then respond to that feedback. Ultimately, a merge request needs to be approved and then merged for the Code Review process to be completed for a given changeset.
In GitLab, Code Review takes place in the merge request. GitLab should make these tasks efficient and easy, so that velocity and code quality and security both increase while allowing for future iterations.
The code review process involves at least two roles (author, and reviewer) but may involve many people, who work together to achieve code quality standards and mentor the author. Furthermore, many reviewers are often not Developers. Reviewers may be Developers, Product Designers, Product Managers, Technical Writers, Security Engineers and more.
In support of GitLab's vision for code review, areas of interest and improvement can be organized by the following themes:
In Progress: Request changes on merge requests
When you've completed your review of a merge request it's important signal to the author what your expecations are. We'll be working to add an additional status when completing your review that shows you're intending for the author to make further changes prior to the merge request being accepted.
In Progress: Automatically merge when merge checks pass
This effort will allow merge requests to be configured to merge when all required checks have passed. This saves time/effort for users who can merge as they don't need to wait for the last approval or some other change, they can just set something to merge and when the merge request is able, it will be merged.
In Progress: Suppress display of generated files
We've begun much of the backend work to be able to identify generated files that might not need diffs. We're now using this to build out user facing changes to improve the usability and performance of merge requests.
Later: Review Rounds
The Review Rounds work is encompassing of efforts like
Request changes on merge requests from above, but continues to build on this effort. We'll be evaluating the opportunities we've uncovered and working to iteratively delivery on continued enhancements to the review experience.
AI Assisted Integrations & Explorations
As GitLab continues to expand it's reach and capabilities with the latest technology around language models and AI assisted workflows we're looking to enhance the merge request workflow with these capabilities.
In Progress: Summarize proposed changes in a merge request
We'll continue to expand our summary efforts on merge requests to improve the experience as we work to mature this feature further. We're currently looking at the quality of the summary and placement of the summary within the merge request.
As we continue to develop ideas for investigation we'll add them to this epic. If you have ideas of things we can explore as part of journey in to this area, please contribute ideas here.
Performance & Reliability Improvements
In Progress: New Diffs Architecture
Diffs are at the center of the merge request within GitLab. We're working on a new architecture for diffs that improves performance and allows us to build more features on top of them.
In Progress: Partition merge_request_diff_* tables
Code Review has a number of tables that can grow in size and resource usage as teams continue usage of merge requests. We're looking to optimize this usage to improve performance and reliablity of GitLab instances.
Research & Design Efforts
In Progress: Review Rounds
Code reviews typically involve multiple rounds of review as feedback is given, iterations made, and re-reviews happen. Understanding which merge requests a user needs to act on and the role they're playing in the merge request is an important part of communicating both state and responsiblity. We're looking in to more structured rounds of reviews to better inform users not only of what action is needed, but also when that action is needed.
AI Assisted Integrations & Explorations
We're continuing to build on summarize the proposed changes in a merge request to make it easier for authors to communicate to reviewers what their changes do. We're focusing on prompt improvements for more accurate summaries as well as UI improvements to where we show the summary.
patch-id to identify diffs - released in GitLab 16.7
Other important issues recently delivered by the group can be seen in this list.
GitLab competes with both dedicated and integrated code review tools. Because merge requests (which is the code review interface), and more specifically the merge widget, is the single source of truth about a code change and a critical control point in the GitLab workflow, it is important that merge requests and code review in GitLab is excellent. Our primary source of competition and comparison is to dedicated code review tools. See the best in class analysis for an overview. For a closer look at the user experience and feature set of competitor tools see these details. (Both links are internal only).
This category is currently at the Loveable maturity level (see our definitions of maturity levels).
Code review is used by software engineers and individual contributors of all kinds. Depending on their context, however, the workflow and experience of code review can vary significantly.
We primarily focus research efforts around Sasha (Software Developer).