Great question! Let's break this down clearly for your local GitLab environment:

GitLab免费版是否内置代码评审系统？ #

Absolutely! GitLab's free Community Edition (CE) comes with a fully built-in code review system—you don't need any extra tools for standard review workflows. The core of this is Merge Requests (MRs), which are GitLab's native way to handle code reviews, and they cover all the essential features most teams need:

• Line-by-line code comments and annotations right in the diff view
• Assign specific reviewers to sign off on changes
• Enforce rules like "at least 1 approval required before merging"
• Track review comments, resolutions, and updates in real time
• Compare branch differences and review code contextually

If your team just needs standard code review processes (no super specialized requirements), stick with GitLab's built-in MR system—it's straightforward and eliminates the overhead of maintaining a separate tool.

When should you integrate Gerrit or other tools? #

Only consider adding a third-party tool like Gerrit if you have specific needs that GitLab CE can't cover, such as:

• Your team is already deeply accustomed to Gerrit's workflow and doesn't want to switch
• You need ultra-strict gatekeeping (e.g., mandatory static analysis passes before reviews can start—Gerrit's hook system is more flexible here)
• You require complex cross-repository review flows or deep integration with legacy toolchains

For 90% of use cases, GitLab's built-in tools will be more than enough.

Setup Steps #

Option 1: Use GitLab Free Edition's Built-in Code Review #

This is the simplest path—here's how to configure it for your local instance:

1. Protect your main branch
   • Log into your local GitLab, navigate to your project, then go to Settings > Repository > Protected branches
   • Select your main branch (e.g., main or master), set it so only merge requests can be used to update it, and restrict direct push access to maintainers only (so developers can't bypass reviews)
2. Create a Merge Request for review
   • Developers create a feature branch from the main branch (e.g., feature/payment-flow), commit code, and push it to GitLab
   • From the project page, click Merge Requests > New merge request, select the feature branch as the source and main branch as the target
   • Add reviewers, write a clear description (what the change does, testing done), and submit the MR
3. Conduct the review
   • Reviewers get notified, open the MR, and leave comments on specific lines or the overall change
   • Developers address feedback, push updates to the feature branch, and the MR automatically refreshes
   • Once satisfied, reviewers click Approve to sign off
4. Merge the code
   • When your approval rules are met (e.g., at least 1 approval), the MR can be merged into the main branch—you can also choose to delete the feature branch afterward to keep things clean

Option 2: Integrate Gerrit with GitLab (If You Need It) #

If you have to use Gerrit alongside GitLab, here's how to set up the local environment:

1. Deploy Gerrit Server
   • Spin up a server (can be the same as your GitLab server or a separate one) with a Java Runtime Environment (JRE)—Gerrit requires Java to run
   • Download the latest Gerrit WAR file, then initialize the server:

     java -jar gerrit-3.8.x.war init -d /opt/gerrit
     

     Follow the setup wizard: choose Git as the repository type, set an HTTP port (e.g., 8081), configure authentication (use LDAP if you want to sync with GitLab's user base), and create an admin account
   • Start the Gerrit service:

     /opt/gerrit/bin/gerrit.sh start
     

2. Sync Gerrit with GitLab
   • In Gerrit, create a new project and set its remote repository to your GitLab project's URL
   • Configure Gerrit's push hooks so that once code passes review, it automatically gets pushed to GitLab's main branch
   • In GitLab, lock down the main branch to only accept pushes from Gerrit—disable direct pushes and MR merges to enforce the Gerrit review gate
3. Set Up the Team Workflow
   • Developers push code to Gerrit's review refs (e.g., refs/for/main) instead of directly to GitLab
   • Reviewers conduct reviews in Gerrit, leave feedback, and approve changes once they're ready
   • After approval, Gerrit auto-pushes the code to GitLab's main branch
   • Optional: Configure webhooks between Gerrit and GitLab to sync review statuses (so GitLab shows when a change has passed Gerrit review)

内容的提问来源于stack exchange，提问作者vivekvroy