gitlab-org / gitlab

Code Review & Quality - gitlab-org/gitlab

Code Review & Quality in GitLab

GitLab provides several features to facilitate code review and ensure code quality. Code review is an essential process that helps improve code and encourages collaboration among team members. GitLab’s inline comments and merge request reviews enable asynchronous code review, making it easier for team members to share feedback across different time zones.

Code Review

Code reviews in GitLab are conducted through merge requests. Merge requests allow team members to have discussions, link to specific lines of code, and resolve threads quickly. GitLab simplifies the review process with Merge Request Reviewers, enabling team members to request a review with just a few clicks. Reviewers can suggest code changes using a simple markdown syntax in a diff.

GitLab provides the following code review features:

  • Inline comments: Facilitate asynchronous code review and feedback by allowing team members to comment on specific lines of code.
  • Merge request reviews: Simplify the review process and help team members request and provide feedback quickly.
  • Code suggestions: Allow reviewers to suggest code changes using a simple markdown syntax in a diff.

Code Quality Analysis Tools

GitLab includes several code quality analysis tools to help teams ensure code quality. These tools include:

  • ESLint: A pluggable linting utility for JavaScript that enforces code consistency and quality.
  • RuboCop: A static code analyzer for Ruby that enforces code consistency and quality.
  • Static Application Security Testing (SAST): Analyzes application code for security vulnerabilities.
  • Dependency Scanning: Analyzes dependencies for known security vulnerabilities.

Code Review Guidelines

GitLab provides the following code review guidelines:

  • Explicitness: Clearly communicate the type of review required to avoid ambiguity.
  • Avoid TODO comments: Adding TODO comments directly to the source code is not recommended. If TODO comments are added due to an actionable task, include a link to the relevant issue.
  • Avoid comments that only explain what the code is doing: Comments should provide context or explain why the code is written a certain way.

GitLab Flow Best Practices

GitLab recommends the following best practices for GitLab Flow:

  • Use feature branches: Make changes in feature branches rather than committing directly to the main branch.
  • Test all commits: Test all commits, not only ones on the main branch.
  • Run every test on all commits: If tests run longer than 5 minutes, they can run in parallel.
  • Perform code reviews before merging into the main branch: Ensure that code is reviewed and approved before merging into the main branch.
  • Deployments are automatic based on branches or tags: Deployments are automatic based on branches or tags.
  • Tags are set by the user, not by CI: Tags are set by the user, not by CI.
  • Releases are based on tags: Releases are based on tags.
  • Pushed commits are never rebased: Pushed commits are never rebased.
  • Everyone starts from main and targets main: Everyone starts from main and targets main.
  • Fix bugs in main first and release branches second: Fix bugs in main first and release branches second.
  • Commit messages reflect intent: Commit messages should reflect the intent of the changes made.

Resources

Additional Resources