Ubuntu20.04搭建gerrit code review

一、环境准备

1. 安装 Java 环境‌

Gerrit 依赖 Java 运行环境（推荐 JDK 8+）：

sudo apt install openjdk-11-jdk

验证安装：

java -version

‌2. 安装 Git

sudo apt install git

‌3. 可选依赖

数据库‌：Gerrit 默认使用 H2，但生产环境建议配置 MySQL 或 PostgreSQL‌

sudo apt install mysql-server

Web 服务器‌：若需通过 Apache/Nginx 代理访问，需提前安装‌

sudo apt install apache2

二、安装 Gerrit‌

1.下载 Gerrit WAR 包‌

从 Gerrit 官网获取 .war 文件，例如 gerrit-3.8.0.war‌23。
注意：从Releases里找到历史版本，每个版本对Java版本有要求，下载符合你需要的版本即可，点击“Release notes for Gerrit3.11”进入里面可以下载
在这里插入图片描述

2‌. 初始化 Gerrit 站点目录‌

通过以下命令初始化 Gerrit 工作目录（如 /var/gerrit）：

java -jar gerrit-3.8.0.war init -d /var/gerrit

按照提示输入配置信息
关键配置项‌：‌

数据库类型‌：选择 H2（测试）或 MySQL（生产）‌。‌
仓库存储路径‌：默认 git，可按需修改（如 /var/gerrit/git）‌。
认证方式‌：选择 HTTP 或 OpenID（推荐 LDAP/OAuth 集成）‌。
SMTP 服务‌：配置邮件通知（需提供 SMTP 服务器信息）‌。

3. 配置 Gerrit‌

如果初始化Gerrit的时候关键配置配错了，还可以修改 gerrit.config‌
文件路径：/var/gerrit/etc/gerrit.config
关键配置示例：
注意：auth的type使用HTTP，这样就能配合服务器上的Apache进行登录用户名和密码认证了

[gerrit]  
  basePath = git  
  canonicalWebUrl = http://localhost:8081  # 反向代理的访问地址‌
[database]  
  type = mysql  # 若使用 MySQL‌:ml-citation{ref="3,4" data="citationList"}  
[auth]  
  type = HTTP          # 使用 HTTP 认证，与 Apache/Nginx 配合实现认证‌，而非 OpenID
  httpHeader = Authorization  # 从 HTTP 头中读取认证信息
  emailFormat = {0}@example.com  # 可选：自动生成用户邮箱（替换为你的域名）
[httpd]
  listenUrl = proxy-http://localhost:8081/  # 确保与代理配置一致

4. 启动 Gerrit 服务

/var/gerrit是上面设置的gerrit站点目录

/var/gerrit/bin/gerrit.sh start

三、Apache配置与访问‌

Web 服务器代理（以 Apache 为例）‌
上面的步骤启动gerrit后，没有用户名和密码就可以登录的。需要配置集成反向代理（Apache）

‌1、启用 Apache 模块‌

sudo a2enmod proxy proxy_http  
sudo systemctl restart apache2

2. 配置 VirtualHost‌

示例配置（/etc/apache2/sites-available/gerrit.conf）

配置 Apache 反向代理至 Gerrit 默认端口（8080）：
修改/etc/apache2/sites-enabled/000-default.conf文件

<VirtualHost *:80 >
    ProxyPass / http://localhost:8080/
    ProxyPassReverse / http://localhost:8080/
    ProxyRequests Off
</VirtualHost>

可以使用appchectl -S 命令查看apache2的配置文件路径
在这里插入图片描述

生成认证文件：htpasswd -c /path/to/htpasswd username
- Gerrit 安装过程中，‌第一个通过认证的用户自动成为管理员
- /path/to/htpasswd该路径和apache2下面的gerrt.conf配置里的AuthUserFile需要一样

# 正确方式：先创建文件（带 -c），后续追加用户（不带 -c）
htpasswd -c /path/to/user_passwd admin  # 首次创建
htpasswd /path/to/user_passwd user2    # 追加 user2

1）修改默认配置文件

如果不想使用默认的/etc/apache2/sites-enabled/000-default.conf文件
而是在/etc/apache2/sites-enabled/下面新增gerrit.conf配置文件

启用站点
仅创建 gerrit.conf 文件不会自动激活站点，需执行命令建立符号链接到 sites-enabled 目录

sudo a2ensite gerrit.conf  # 启用配置并生成软链接‌

启用关键模块
Gerrit 反向代理需依赖以下模块

sudo a2enmod proxy proxy_http rewrite  # 启用代理和重写模块‌

重启apache2

sudo systemctl restart apache2 # 重启服务使新配置生效‌

验证模块加载

apache2ctl -S

快速检查

sudo a2ensite gerrit.conf #启用站点  
sudo a2enmod proxy proxy_http #启用模块  
sudo apachectl configtest #检测配置文件中是否有语法错误（如拼写错误或指令冲突）‌
sudo systemctl restart apache2 # 重启服务  
curl -I http://localhost #验证响应状态

防火墙设置

开放 Apache 监听端口（如 80/443）或关闭防火墙临时测试

sudo ufw allow 80  # 允许 HTTP 流量‌

2）修改监听端口

修改80端口为8088

修改配置文件gerrit.conf

<VirtualHost *:8088>

修改/etc/apache2/ports.conf
监听端口匹配‌：确保 gerrit.conf 中的 <VirtualHost *:80> 与 ports.conf 中定义的端口一致‌
新增一行Listen 8088，如果80不使用可以直接将80改成8088

Listen 8088

3) 配置模版

该配置只对login的路径即点击登录才会进行认证

<VirtualHost *:8080>
  ServerName 127.0.0.1
  ProxyRequests Off
  ProxyPreserveHost On
  ProxyPass / http://localhost:8081/
  ProxyPassReverse / http://localhost:8081/
  
  <Location "/login/">
    AuthType Basic
    AuthName "Gerrit Code Review"
    AuthUserFile /home/gerrit/account/.htpasswd
    Require valid-user
  </Location>
</VirtualHost>

强制所有请求进行 Basic 认证

<VirtualHost *:8080>
  ServerName localhost
  ProxyRequests Off
  ProxyPreserveHost On
  ProxyPass / http://localhost:8081/
  ProxyPassReverse / http://localhost:8081/

  # 仅对根路径启用认证
  <Location "/">
    AuthType Basic
    AuthName "Gerrit Code Review"
    AuthUserFile /home/gerrit/account/.htpasswd
    Require valid-user
    # 将认证信息传递给 Gerrit
    RequestHeader set Authorization "expr=%{HTTP:Authorization}"
  </Location>
</VirtualHost>

注意：Apache 的 RequestHeader 指令属于 ‌mod_headers 模块，所以需要开启该模块

sudo a2enmod headers  # 启用 headers 模块

四、Gerrit code review页面配置

版本是3.9.9版本，2.x的老版本页面和这个不一样

1. 创建项目–只有管理员有权限

BROWSE->Respositories->CREATE NEW
在这里插入图片描述
填写仓库名等信息，如果需要创建子仓库(例如a仓库下有一个子仓库)，那么子仓库名填写成a/b
注意：项目需要添加Create Reference‌权限 --见下面的3.1.1.2 Add permission选项

2、查看和拉取仓库

BROWSE->Respositories->Respositoreies->选择项目
在这里插入图片描述
General->Download->HTTP/SSH
终端输入命令就可以下载代码了

Clone
标准的Clone操作仅克隆仓库的代码，不包含任何额外的配置或钩子。
Clone with commit-msg hook
在克隆仓库的同时，还会安装一个commit-msg钩子，该钩子用于在提交信息不符合规范时阻止提交，适用于需要强制提交信息规范的团队或项目

HTTP和SSH下载代码都需要密钥，在设置里添加

1) HTTP下载代码

HTTP Credentials-》GENERATE NEW PASSWORD
在这里插入图片描述
会自动生成密码，需要自己记住，web上不会显示该密码，忘记了就重新生成。
该密码在终端通过HTTP下载代码的时候会提示输入的

2) SSH下载代码

需要在终端通过命令ssh-keygen 命令生成密钥

ssh-keygen -t rsa -b 4096 -C "user@mail.com"

注意：从 OpenSSH 8.2 开始，默认禁用了 RSA 密钥类型，主要是为了提高安全性。这可能意味着默认情况下不接受某些类型的 RSA 密钥。
解决：在/etc/ssh/ssh_config添加 PubkeyAcceptedAlgorithms +ssh-rsa
或者用ecdsa密钥类型

ssh-keygen -t ecdsa -b 521 -C "user@mail.com"

将~/.ssh/id_ecdsa.pub的内容拷贝到该下面表单里
然后点击ADD NEW SSH KEY

如果不添加SSH KEY，终端下载代码会报错

Permission denied (publickey).
fatal: 无法读取远程仓库。
请确认您有正确的访问权限并且仓库存在。

3、权限控制

3.1 禁止直接推送代码到仓库

1）限制直接推送至 `refs/heads/master`

找到Reference: refs/heads/*，将其下面的push配置设置为Deny。或者你可以选择只有管理员有权限，其他人没有权限
在这里插入图片描述

2）强制代码提交至评审分支 `refs/for/master`

找到Reference: refs/for/*，分配 Push 权限为 ‌Allow

3.1.1 不同引用（references）的区别

‌引用路径	核心用途	典型操作场景
refs/heads/*	本地分支存储	直接推送代码（需权限限制）
refs/tags/*	版本标签存储	标记稳定版本
refs/for/*	Gerrit 代码评审触发路径	提交代码至评审流程
refs/meta/config	仓库权限与配置管理	修改项目访问规则
refs/*	全局引用匹配	批量权限控制（如禁用匿名访问）

基础分支与标签引用‌
- refs/heads/*‌
  - 用途‌：存储本地分支的指针，对应 git branch 创建的分支（如 refs/heads/master 表示 master 分支）‌。
  - 操作限制‌：直接推送至该路径会绕过代码评审（Gerrit 场景下需禁止此操作)
- refs/tags/*‌
  - 用途‌：存储标签（如版本号 v1.0），通常用于标记稳定版本‌。
  - 操作特性‌：标签一般不可变（轻量标签或附注标签）‌
Gerrit 代码评审专用引用
- refs/for/*‌‌
  - 用途‌：Gerrit 强制代码评审的推送目标路径（如 git push HEAD:refs/for/master），提交后生成评审任务‌。
  - 格式简化‌：refs/for/master 等价于 refs/for/refs/heads/master，后者为完整路径但前者更常用‌。
- refs/for/refs/*‌
  - 误解澄清‌：此路径非常规用法，Gerrit 中实际使用 refs/for/（如 refs/for/master）触发评审，无需额外嵌套 refs‌。
元数据与配置引用‌
- refs/meta/config‌
  - 用途‌：存储仓库的权限配置（如 project.config 文件）、用户组规则等‌34。
  - 操作权限‌：仅管理员可修改，直接影响项目访问控制‌3。
- refs/meta/version‌
  - 用途‌（推测）：存储仓库元数据版本信息（如 Gerrit 插件或系统版本）。
通配符与全局引用‌
- refs/*‌
  - 用途‌：匹配所有引用路径（如 refs/heads/、refs/tags/），常用于全局权限配置‌。
  - 权限示例‌：设置 refs/* 的 Read 权限可控制所有分支和标签的可见性‌

3.1.1.2 Add permission选项

Label Verified‌：此权限允许用户验证标签，确保标签的正确性和有效性。
Label Verified (On Behalf Of)‌：此权限允许用户代表其他人验证标签，这在团队协作中非常有用，特别是当某个成员无法自行验证时。‌
Label Code-Review‌：此权限允许用户进行代码审查，确保代码的质量和一致性。‌
Label Code-Review (On Behalf Of)‌：与“Label Verified (On Behalf Of)”类似，此权限允许用户代表其他人进行代码审查。‌
Abandon‌：此权限允许用户放弃某个版本或分支，这在需要撤销或忽略某些更改时非常有用。‌
Add Patch Set‌：此权限允许用户向现有的更改集中添加新的补丁集，以便进行进一步的修改和完善。
Create Reference‌：此权限允许用户创建新的引用，如分支或标签，这对于版本控制和代码管理至关重要。‌
Create Signed Tag‌：此权限允许用户创建签名标签，这有助于确保标签的真实性和完整性。‌
Create Annotated Tag‌：与签名标签类似，带注释标签提供了更多的上下文信息，此权限允许用户创建这样的标签。‌
Delete Reference‌：此权限允许用户删除分支或标签，这在清理不再需要的版本或标记时非常有用
Delete Changes‌：此权限允许用户删除他们自己的更改，这在需要撤销某些操作时非常有用。‌
Delete Own Changes‌：与“Delete Changes”类似，但此权限通常仅限于用户删除自己的更改，以确保不会意外删除他人的工作。‌
Edit Hashtags‌：此权限允许用户编辑哈希标签，这对于在代码库中进行更好的组织和搜索非常有用。‌
Edit Topic Name‌：此权限允许用户编辑主题名称，有助于在版本控制系统中更好地组织和跟踪更改。
Forge Author Identity‌：此权限允许用户以其他用户的身份提交代码，这在某些特殊情况下可能有用，但需要谨慎使用以避免混淆和安全问题。‌
Forge Committer Identity‌：与“Forge Author Identity”类似，此权限允许用户以其他提交者的身份进行提交。‌
Forge Server Identity‌：此权限允许用户以服务器的身份进行操作，这在某些自动化或管理任务中可能非常有用，但同样需要谨慎使用以避免安全问题。
Forge Server Identity‌：允许用户以服务器身份伪造提交者或作者信息，通常用于自动化脚本或镜像同步场景，需谨慎分配以避免安全风险‌。
Owner‌：表示用户对特定代码变更（Change）的所有权，拥有者可修改元数据、添加审查者或执行提交操作，通常与代码审查流程中的管理权限相关‌。
Push‌：允许用户将本地代码提交推送到远程仓库的分支，普通用户一般仅能推送到特定分支（如开发分支），管理员可能拥有更广泛的推送权限‌。
Push Merge Commit‌：控制用户是否允许推送合并提交（Merge Commit），需配合分支策略使用，防止因合并冲突导致历史混乱‌。
Rebase‌：授予用户对提交历史执行变基操作的权限，例如将本地分支的提交基于远程最新代码重组，需注意避免破坏他人工作‌。
Remove Reviewer‌：允许用户从代码审查流程中移除已添加的审查者，通常由变更所有者或管理员使用，以确保审查流程高效推进‌。
Revert Submit (On Behalf Of)‌：支持用户撤销已合并的提交（生成反向提交），或以他人身份执行撤销操作，适用于修复错误但需保留历史记录的场景‌。
Toggle Work In Progress State‌：允许用户将代码变更标记为“进行中”（WIP）或“完成”，用于控制变更是否可被合并，便于协作时区分任务状态‌。
View Private Changes‌：授予用户查看非公开变更（如标记为私有的代码审查）的权限，通常用于内部敏感项目或未公开功能开发

补充说明‌
权限粒度：Gerrit通过权限组（如refs/*）控制不同分支或路径的操作范围，例如限制Push仅作用于refs/heads/dev分支‌。
身份伪造风险：Forge Server Identity和Forge Committer Identity需严格审核，避免恶意用户伪造他人身份提交代码‌。
协作流程：Rebase和Push Merge Commit的权限分配应结合团队代码合并策略（如禁止快进合并）‌