openEuler部署Gitblit：中小团队内网Git服务器搭建全攻略

1. 项目背景与整体思路

先说结论：Gitblit 是我用下来最适合中小团队“内网自建 Git 服务”的方案之一，尤其是在 openEuler 这种国产 Linux 发行版上，部署流程清爽、依赖少、维护成本极低。你不需要像搭建 GitLab 那样准备 8G 内存和一堆 Ruby 组件，Gitblit 就是一个 Java 写的 WAR 包，内置 Jetty 容器，拷过去改两行配置就能跑起来。

我这边是在 openEuler 22.03 LTS SP4 上完成的部署，内核版本 5.10，架构 x86_64，选这个版本主要是因为它属于长期支持版本，安全更新和维护周期都拉得比较长，适合服务器环境。整个过程可以分为五个阶段：环境准备（虚拟机配置、yum 源）、Java 运行环境搭建、Gitblit 程序部署、仓库与用户体系初始化、日常维护与备份。每个阶段都有几个容易踩坑的细节，我会把实测过的操作和排查思路都写出来。

这个项目适合谁来参考？如果你是中小型研发团队的运维或后端开发，公司没有预算上付费版的 Git 托管服务，又想在内网有一套带 Web 界面、支持权限控制的 Git 服务器，那 Gitblit 几乎是最省事的选择。另外，如果你刚接触 openEuler，想找个练手项目把系统配置、yum 源、Java 环境、服务管理这些基础技能串起来，跟着这篇文章完整走一遍也会非常有收获。

2. 环境准备：虚拟机设置与 yum 源配置

2.1 虚拟机安装 openEuler 的关键设置

如果你打算用虚拟机跑 Gitblit，VirtualBox 或者 VMware 都可以，我用的 VirtualBox 7.0 系列，实测下来需要注意这么几个地方。

第一，操作系统类型要选 Linux 和 Red Hat（64-bit），不要选 Other Linux，否则 VirtualBox 不会加载对应的虚拟化优化参数。openEuler 的内核与 RHEL 系保持兼容，选 Red Hat 类型能让虚拟机在 CPU 指令集模拟和 I/O 控制器上有更好的兼容性。

第二，显存设置建议给到 32MB 以上，虽然服务器不需要桌面环境，但安装引导界面和终端界面都需要基本的显存支持，给太小会在图形化安装界面出现花屏或者界面卡死。

第三，磁盘分配方面，最小化安装 Gitblit 服务器，20GB 就够用，但如果后续还要装 Docker、跑 CI 流水线、存放大量 Git 仓库历史数据，建议直接给 40GB，省得后面扩容麻烦。分区方案就用系统默认的 LVM，swap 给 2GB 即可，Java 应用跟 swap 的配合反而需要留意，后面展开讲。

第四，网络模式建议用桥接而不是 NAT。因为 Gitblit 是要给团队其他人访问的，NAT 模式下宿主机外的设备访问不到虚机，就算做了端口转发，SSH 克隆仓库的地址写起来也非常别扭。桥接模式下 Gitblit 服务会直接暴露在局域网，团队成员用 IP 就能访问。这一点在装系统之前就定下来，后面配置会顺手很多。

安装完成进入系统后，建议第一时间做两件事：一是配置主机名，hostnamectl set-hostname git-server，二是关闭 SELinux 或者在部署完成后放行对应端口，后面细讲。

2.2 openEuler 的 yum 源配置技巧

openEuler 系统装好之后默认配置的是官方源，但国内网络环境下从官方源拉包经常会比较慢，甚至超时。所以第一步建议换成国内镜像源。

操作上很简单，备份默认源配置后，直接拉取镜像站的 repo 文件。

bash复制mv /etc/yum.repos.d/openEuler.repo /etc/yum.repos.d/openEuler.repo.bak
curl -o /etc/yum.repos.d/openEuler.repo https://mirrors.tuna.tsinghua.edu.cn/openeuler/openEuler-22.03-LTS-SP4/extras/x86_64/repodata/...

这里说明一下，清华源和阿里源都有 openEuler 的镜像仓库，我习惯用的是清华源。可以在 https://mirrors.tuna.tsinghua.edu.cn/openeuler/ 下找到对应版本和架构的仓库地址，里面有 openEuler.repo 文件可以直接下载。如果你不想用 curl 拉文件，也可以手动编辑 repo 文件，核心就是把 baseurl 指向镜像路径，把 gpgcheck 设为 0 或者保留 1 并导入对应的 GPG key。

配置完成后执行：

bash复制dnf clean all
dnf makecache

makecache 成功后，dnf install 的速度会有非常明显的提升。openEuler 22.03 默认用的包管理器是 dnf，兼容 yum 命令写法，两个命令在这版本上都可以用，但 dnf 是更推荐的底层实现。我这个阶段实测下来，配置好国内源之后装 Java 的速度从原来可能等两三分钟，变成几秒钟就能完成。

2.3 最小化安装还是带桌面？

很多朋友看搜索词里有“openEuler 安装桌面版”，会纠结要不要装个桌面再部署服务。我的建议：跑 Gitblit 这种纯服务端的场景，完全没有装桌面的必要，用最小化安装能减少一半以上的系统更新包和攻击面。Java 服务和 Web 管理界面都不依赖图形环境，日常维护靠 SSH 远程操作完全够用。

如果你装系统选了 Server 带桌面的安装方式也没关系，不影响 Gitblit 部署。只是后面要多留意桌面环境自带的 NetworkManager 和防火墙策略可能会对端口放行有干扰，排查问题的时候多个心眼。

3. Java 运行环境搭建

3.1 Gitblit 需要哪个版本的 Java

Gitblit 1.9.3 是目前的最新稳定版本，官方明确要求 Java 8 及以上，官方文档里推荐用 Java 8 运行。这里有个容易忽略的细节：Gitblit 的 service.sh 脚本（用于注册成系统服务）和 gitblit.sh 启动脚本对 Java 的查找逻辑稍有不同，但都需要 JAVA_HOME 环境变量能被正确找到。

在 openEuler 22.03 上，系统软件源里同时提供了 Java 1.8 和 Java 11 的包。对于 Gitblit 1.9.3，实测用 Java 1.8 是最稳妥的。Gitblit 1.9.x 的某些插件和 LDAP 认证模块在 Java 11 上会有兼容性问题，虽然核心功能能用，但不建议生产环境这么干。如果你后续计划升级到更新的 Gitblit 版本，再考虑使用 Java 11 或 17。

3.2 安装 Java 1.8

在 openEuler 上安装 Java 1.8 非常直接，包名就是 java-1.8.0-openjdk：

bash复制dnf install -y java-1.8.0-openjdk

装完后验证版本：

bash复制java -version

如果输出类似 openjdk version "1.8.0_xxx"，就说明装好了。对于 Gitblit 这种服务端应用，只需要 JRE 即可，不需要安装 JDK 的编译工具链，所以 java-1.8.0-openjdk 就够了，java-1.8.0-openjdk-devel 可以不装。

这里有个小知识点：openEuler 的 OpenJDK 包安装后会把 java 二进制链接到 /usr/bin/java，同时设置了 /etc/profile.d/java.sh 里的 JAVA_HOME。但 /etc/profile.d 里的环境变量只在登录 shell 里生效，如果你用 systemd 服务方式启动 Gitblit，需要确保 systemd 单元文件里能拿到这个变量，这个坑后面在服务注册部分会重点说。

3.3 JAVA_HOME 配置与验证

虽然系统默认设置了 JAVA_HOME，我还是建议在 /etc/profile.d/ 下新建一个专用的环境变量文件，避免后续其他 Java 应用互相干扰。

bash复制cat > /etc/profile.d/gitblit-java.sh << 'EOF'
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk
export PATH=$PATH:$JAVA_HOME/bin
EOF
source /etc/profile.d/gitblit-java.sh
echo $JAVA_HOME

/usr/lib/jvm/java-1.8.0-openjdk 这个路径在 openEuler 上是固定存在的，它其实是个软链接，指向实际的 JDK 安装目录。如果你用 alternatives --config java 切换过 Java 版本，这个软链接路径也会跟着变，所以配置环境变量时直接用这个稳定路径是最省心的。

验证阶段可以用一条命令确认 Java 真的可用：

bash复制$JAVA_HOME/bin/java -version

这一步没问题的前提下，Gitblit 的启动才不会报 Unable to locate Java 之类的错。Java 环境是 Gitblit 的命根子，95% 的启动失败都是环境变量没配对导致的。

4. Gitblit 下载、解压与初始化配置

4.1 下载 Gitblit 与目录规划

Gitblit 官方提供了两种发布包：一种是免安装的 gitblit-1.9.3.tar.gz，里面已经包含了 Jetty 容器，解压就能用；另一种是 WAR 包，需要自己放到 Tomcat 等外部容器里运行。我强烈推荐用免安装的 tar.gz 包，理由很简单：少一个中间层就少一个故障点，自带的 Jetty 配置和 Gitblit 深度适配，启动参数、内存设置、日志路径都是现成的，省去大量调优工作。

下载地址是 https://github.com/gitblit/gitblit/releases，选择 gitblit-1.9.3.tar.gz 即可。由于 GitHub 下载在国内网络环境下时快时慢，你可以先在本地下载好再传到服务器，或者直接在服务器上用 wget 拉取：

bash复制cd /opt
wget https://github.com/gitblit/gitblit/releases/download/v1.9.3/gitblit-1.9.3.tar.gz
tar -zxvf gitblit-1.9.3.tar.gz
mv gitblit-1.9.3 gitblit

目录规划上，我把 Gitblit 放在 /opt/gitblit，数据和配置文件都在这个目录下，逻辑清晰，备份时直接打包这个目录就行。Gitblit 解压后里面有几个关键目录和文件：

• gitblit.properties：主配置文件
• defaults.properties：默认配置模板，不要修改它
• data：默认的数据目录，存放 H2 数据库（用户、仓库元数据、权限配置）
• git：默认的 Git 仓库根目录
• logs：运行日志目录
• gitblit.sh / service.sh：启动脚本和服务注册脚本

4.2 修改核心配置项

在启动之前，你需要编辑 /opt/gitblit/data/gitblit.properties，这个文件在首次启动后会生成。如果解压后还没有 data 目录，可以先运行一次 gitblit.sh 让它自动生成，或者手动创建。我习惯是先手动创建 data 目录再改配置，这样更可控。

bash复制mkdir -p /opt/gitblit/data
cp /opt/gitblit/gitblit.properties /opt/gitblit/data/gitblit.properties

然后编辑 gitblit.properties，重点配置以下几项：

properties复制# HTTP 端口，默认是 8080，建议改成 8443 或者保持 8080
httpPort = 8080
# HTTPS 端口，如果要启用 HTTPS 就配置证书路径
httpsPort = 8443

# Gitblit 对外访问的基础 URL，这里要改成服务器的 IP 或域名
gitblit.url = http://192.168.1.100:8080

# 仓库根目录
git.repositoriesFolder = /opt/gitblit/data/git

# H2 数据库文件路径
database.store = /opt/gitblit/data/gitblit.h2.db

有几个点需要重点说明。

gitblit.url 这个配置很多人会忽略，但它会直接影响 Web 界面上“克隆地址”的显示。如果你的服务器 IP 是 192.168.1.100，却保留了默认的 localhost，Web 界面上生成的 clone URL 就是 http://localhost:8080/git/xxx.git，团队成员拿到这个地址肯定连不上。所以这个地址务必改成实际的 IP 或者你配好的域名。

git.repositoriesFolder 是仓库的实际存储路径，默认在 data/git 下。由于 Gitblit 数据目录和仓库目录都在 data 里，备份时打包 data 目录就全部搞定了，非常推荐保持这个默认相对路径，不要改到 /var/git 之类的地方，分散路径会给自己找麻烦。

httpPort 默认是 8080，如果被其他服务占了可以改掉，Gitblit 也支持同时启用 HTTPS 端口，但内网环境一般没必要，HTTP 就够了。如果你选择启用 HTTPS，需要额外生成证书并配置 server.keystore，这个后面可以单独写一篇，这里不展开。

4.3 启动方式一：交互式启动

修改完配置后，直接运行启动脚本：

bash复制cd /opt/gitblit
chmod +x gitblit.sh
./gitblit.sh

看到类似 [main] INFO org.eclipse.jetty.server.Server - Started @ 1234ms 这样的日志就说明启动成功了。此时用浏览器访问 http://192.168.1.100:8080，会出现 Gitblit 的 Web 界面，默认管理员账号是 admin，密码是 admin。

第一次登录后系统会强制要求修改密码，这个逻辑是内置的，不要跳过，设置一个复杂密码再继续。这里的 H2 数据库是 Gitblit 用来存用户、团队、仓库权限映射关系的，不是存仓库内容的，仓库内容以 Git 原生格式存储在 data/git 目录下。

4.4 启动方式二：注册成 systemd 服务

交互式启动只适合临时测试，服务器重启后就没了，所以我们要注册成 systemd 服务。Gitblit 自带了一个 service.sh 脚本，在 Ubuntu 的 sysvinit 体系下可以直接用 service gitblit start 管理，但 openEuler 用的是 systemd，需要自己写一个 unit 文件。

先创建一个专用运行用户，安全考虑建议不要用 root 跑 Gitblit：

bash复制useradd -r -m -d /home/gitblit -s /bin/bash gitblit
chown -R gitblit:gitblit /opt/gitblit

然后创建 systemd 服务文件 /etc/systemd/system/gitblit.service：

ini复制[Unit]
Description=Gitblit Git Server
After=network.target

[Service]
Type=forking
User=gitblit
Group=gitblit
Environment=JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk
ExecStart=/opt/gitblit/gitblit.sh
ExecStop=/opt/gitblit/service.sh stop
PIDFile=/opt/gitblit/data/gitblit.pid
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

这里有个关键细节：Type=forking 表示启动脚本会 fork 出子进程，systemd 通过 PIDFile 跟踪实际的服务进程。Gitblit 的 gitblit.sh 脚本在启动时会把 PID 写入 data/gitblit.pid，所以 PIDFile 的路径必须和脚本里一致。

After=network.target 确保网络服务就绪后再启动 Gitblit。Environment=JAVA_HOME 这一行不是多余的，systemd 服务环境不会加载 /etc/profile.d 下的变量，必须显式指定，否则 Gitblit 会因为找不到 Java 而启动失败。

注册并启动服务：

bash复制systemctl daemon-reload
systemctl enable gitblit
systemctl start gitblit
systemctl status gitblit

执行 systemctl status 输出 active (running) 就说明服务已经托管成功了。以后 reboot 机器，Gitblit 会自动启动。

4.5 防火墙与端口放行

openEuler 默认开启了 firewalld，所以就算 Gitblit 进程起来了，外部设备访问 8080 端口也会被防火墙拦截。这是新手最容易卡住的点。

bash复制firewall-cmd --zone=public --add-port=8080/tcp --permanent
firewall-cmd --reload
firewall-cmd --list-ports

执行完这几条命令后，8080 端口才会对局域网开放。如果你前面在虚拟机配置里选了 NAT 模式，这里还需要在 VirtualBox 里做端口转发，桥接模式下就不用。另外顺便说一句，Gitblit 自带 SSH 服务端口是 29418，如果团队想用 SSH 协议克隆仓库，也要放行这个端口：

bash复制firewall-cmd --zone=public --add-port=29418/tcp --permanent
firewall-cmd --reload

SSH 协议是 Gitblit 的一个亮点，它自带了 SSH daemon，不需要额外安装 openssh-server，这也是很多人用 Gitblit 而不是纯裸仓库的关键原因——团队可以用真正的 git clone ssh://git@host:29418/repo.git 方式拉取代码，而不用走 HTTP 的 Basic Auth。

5. 仓库创建、用户权限与团队管理

5.1 创建第一个仓库

Gitblit 的 Web 界面设计得非常直观，左侧菜单栏有仓库、用户、团队、活动等入口。创建仓库前建议先规划好命名规范，比如 team-project-xxx，或者按 group/repo 的方式组织。Gitblit 原生支持在仓库名称中使用 /，比如 backend/user-service.git 会创建目录层级 backend/user-service.git，这样仓库一多也不会乱。

创建仓库时要注意几个选项的含义：

• Repository Name：仓库名称，建议以 .git 结尾，比如 backend/user-service.git，这样生成的克隆地址更直观。
• Access Restriction：访问控制级别，建议选 View 或 Push。选 View 表示匿名用户可以查看，但不允许提交；选 Push 表示任何人可以克隆和推送；推荐选 View 配合后面的权限配置。
• Federation：联邦功能，用于多 Gitblit 实例间的仓库镜像复制，单机部署不需要开。
• Show Remote / Show Readme 之类的显示选项，默认即可。

创建完成之后，Web 界面上会显示两种克隆地址：HTTP 地址是 http://192.168.1.100:8080/git/backend/user-service.git，SSH 地址是 ssh://git@192.168.1.100:29418/backend/user-service.git。这里的用户 git 是 Gitblit 内置的 SSH 虚拟用户，不是系统用户，权限映射关系由 Gitblit 自己管理。

5.2 创建用户与团队

Gitblit 的权限模型分三层：用户、团队、仓库。用户是最小单位，团队是一个或多个用户的集合，权限可以设置在用户级也可以设置在团队级，仓库的权限则绑定到用户或团队。

创建一个新用户的操作路径：用户管理 → 新建用户。需要设置用户名、密码、邮箱，还可以指定该用户的 SSH 公钥。这里有个实用技巧：让团队成员把本地 ~/.ssh/id_rsa.pub 内容发给你，导入到 Gitblit 用户信息里，他们就能用 SSH 协议克隆和推送代码，不用每次输密码。

团队管理方面，建议按项目来划分，比如 backend-team、frontend-team，然后把对应仓库的权限授予团队。这样管理员只需要维护团队和仓库的映射关系，不需要逐个用户授权。团队的权限在仓库编辑页面里配置，可以授予只读（Read）、读写（Push）、管理（Manage）三种级别的权限。Manage 级别应该只给少数核心维护者，拥有 Manage 权限的人可以修改仓库描述、管理分支、执行清理等操作。实践中，请只给团队负责人授 Manage，其他成员一律 Push 权限。

5.3 本机初始化仓库并推送代码

在本地开发机上验证一下整个流程是否通畅。假设你本地已经有项目代码：

bash复制cd /path/to/your-project
git init
git add .
git commit -m "init project"
git remote add origin http://192.168.1.100:8080/git/backend/user-service.git
git push -u origin master

如果你在 Gitblit 里设置了 HTTP 方式的认证，推送时输入对应用户名和密码即可。这里有个容易忽略的细节：Gitblit 的 HTTP 推送走的是 git-receive-pack 服务，首次推送时如果仓库是通过 Web 界面创建的，HEAD 分支可能还没有指向任何提交，推送一个新的 master 分支是没问题的。但如果你在 Web 界面创建仓库时勾选了“初始化 README”选项，仓库里就有一个初始提交，本地推送的 history 和远端 history 无关联，会直接报错 refusing to merge unrelated histories。遇到这种情况，可以用 git pull --allow-unrelated-histories origin master 先合并再推送，或者干脆不初始化 README，在 Web 界面创建时不要勾选那个选项。

SSH 方式推送的命令也补一下：

bash复制git remote add origin ssh://git@192.168.1.100:29418/backend/user-service.git
git push -u origin master

SSH 推送走的是 Gitblit 自带的 SSH daemon，和 HTTP 是两套认证体系，但用户是同一个人，公钥导入一次就能永久免密操作。

6. 常用维护操作与备份恢复

6.1 日志查看与常见问题定位

Gitblit 运行时的日志默认在 /opt/gitblit/data/logs/ 目录下，有 gitblit.log 和 jetty.log 两个文件。gitblit.log 记录的是 Gitblit 自身的业务日志，包含用户登录、仓库操作、权限校验等；jetty.log 记录的是 HTTP 容器的访问日志。

排查问题的时候，第一反应去看 gitblit.log 的 ERROR 或 WARN 级别信息。常见异常比如：

bash复制tail -f /opt/gitblit/data/logs/gitblit.log

如果日志显示 java.net.BindException: Address already in use，说明 8080 端口被其他进程占用了。解决办法有两种：换端口，或者找到占用进程并处理：

bash复制netstat -tlnp | grep 8080
lsof -i:8080

lsof 命令在 openEuler 上需要额外安装 lsof 包，netstat 则属于 net-tools 包，默认最小化安装下这两个都不一定有。建议直接装上备用：

bash复制dnf install -y net-tools lsof

另一个很常见的报错是 Gitblit 页面能打开，但克隆时提示 not authorized。排查步骤：确认用户在 Gitblit 里是否存在、仓库访问权限是否配置正确、用户密码是否输入正确。如果用的是 SSH 协议，还要检查公钥是否导入成功。这个流程可以按顺序过一遍，基本都是配置问题，不需要动代码。

6.2 每日备份策略

Gitblit 的数据全在 /opt/gitblit/data 目录下，备份策略其实就是一个 tar 包的事。线上规模小的团队，可以写一个简单的定时任务，每天晚上压缩打包数据目录，保留最近 7 天的备份。

bash复制mkdir -p /backup/gitblit
cat > /usr/local/bin/backup-gitblit.sh << 'EOF'
#!/bin/bash
BACKUP_DIR=/backup/gitblit
DATE=$(date +%Y%m%d)
tar -czf $BACKUP_DIR/gitblit-$DATE.tar.gz -C /opt/gitblit data
find $BACKUP_DIR -name "gitblit-*.tar.gz" -type f -mtime +7 -delete
EOF
chmod +x /usr/local/bin/backup-gitblit.sh

再把这个脚本加入 crontab：

bash复制crontab -e
0 2 * * * /usr/local/bin/backup-gitblit.sh

这里有个细节要留意：备份前最好先 gitblit 服务短暂停止或者接受数据出现轻微不同步的风险。实际上 Gitblit 仓库的数据在 push 时已经完整落盘，H2 数据库在写入时也支持热备份，但为了避免压缩过程中 H2 数据库的 WAL 日志被占用，更稳妥的做法是备份前用 curl "http://127.0.0.1:8080/api/..." 之类的接口触发一次 FS 同步，或者干脆接受这种极小概率不一致——Gitblit 是轻量级应用，备份时长通常在秒级，凌晨 2 点做热备份出问题的概率非常低，实测没有问题。

6.3 数据恢复流程

万一服务器挂了或者迁移环境，恢复流程也很直接：

1. 新机器装好 openEuler、Java 8。
2. 把备份的 gitblit.tar.gz 解压到 /opt/gitblit/。
3. 启动服务 systemctl start gitblit。
4. Web 界面登录，确认用户、团队、仓库都回来了。

需要注意两个位置：如果新机器的 IP 变了，要同步修改 gitblit.properties 里 gitblit.url 的地址，否则克隆链接显示旧地址。另外 SSH 公钥是存在 H2 数据库里的，所以还原数据库后公钥也会自动恢复，团队成员不需要重新导入。这一步很关键，说明备份 H2 数据库而不是只备份仓库目录，才是完整的备份。

6.4 容器化部署的取舍

很多朋友看到搜索词里有“openEuler 安装 docker”就想着把 Gitblit 容器化。Gitblit 官方没有维护 Docker 镜像，社区镜像质量参差不齐，而且 Gitblit 的存储结构和容器卷挂载搭配起来并没有想象中省事。

我自己实测过容器化方案，踩了几个坑后发现还是裸机部署最稳妥。主要原因有几个：一是 Gitblit 对 JVM 内存和文件句柄的要求比较敏感，容器里调优不如宿主机直接调；二是数据目录、日志、配置分散在不同挂载点，运维复杂度反而上升；三是 Gitblit 自带的 service.sh 脚本和 systemd 结合得非常紧密，裸机部署的故障排查路径最短。

所以我的建议是：Gitblit 没必要容器化。如果你希望整体用容器管理，可以考虑用 Podman 拉一个通用 Java 镜像跑 WAR 包，但这需要额外配置 Tomcat 连接器、环境变量、数据卷，属于把简单问题复杂化。Gitblit 本身就是个轻量级服务，裸机部署运维负担已经很低了，再利用 Docker 反而会增加镜像兼容性和存储驱动的不确定因素。

7. 安全加固与访问优化

7.1 修改默认端口与禁用弱密码

默认的 8080 端口太显眼，内网扫描一下就能找到对外开放的服务。虽然没有必要搞得像堡垒机一样，但顺手改掉默认端口是低成本高收益的做法。

在 gitblit.properties 里把 HTTP 端口改成比如 8642：

properties复制httpPort = 8642

同时更新 gitblit.url：

properties复制gitblit.url = http://192.168.1.100:8642

然后防火墙放行新端口即可。这一步做不做看你的安全需求，如果内网环境比较干净，8080 也不是不能用，但改一下也没什么成本。

密码策略方面，Gitblit 支持在 Web 界面设置最小密码长度和复杂度。路径是 管理 → 设置 → 基本设置，把最小密码长度设为 8，并开启密码复杂度检查。这个配置是全局的，新建和修改密码都受约束。实测有效降低“admin/123456”这种账号出现的概率。

7.2 启用 HTTPS 还是继续用 HTTP？

内网 Git 服务器是否启用 HTTPS，取决于团队的安全要求和网络环境。如果你只是在内网交换机下开发，HTTP 基本够用，因为 Git 仓库的代码在局域网传输，被中间人截获的概率极低。但如果公司有合规审计要求，或者仓库涉及敏感数据且网络环境不可控，那么 HTTPS 是必须的。

Gitblit 启用 HTTPS 的方法在 gitblit.properties 里配置 server.keystore、server.storePassword 等参数，使用自签名证书即可。关键步骤是先用 keytool 生成一个 PKCS12 格式的密钥库：

bash复制keytool -genkeypair -alias gitblit -keyalg RSA -keysize 2048 -storetype PKCS12 -keystore /opt/gitblit/data/gitblit.keystore -storepass yourpassword -validity 3650 -dname "CN=git.example.com"

然后在配置里打开 HTTPS：

properties复制server.httpsPort = 8443
server.keystore = /opt/gitblit/data/gitblit.keystore
server.storePassword = yourpassword

重启服务后，访问 https://192.168.1.100:8443 会看到证书警告，团队成员把自签名证书导入本机信任库后就能消除警告。这里的自签名证书有个坑：如果 Gitblit 的 URL 配置的是 IP，而证书的 CN 是域名，浏览器会提示域名不匹配，所以证书 CN 最好直接写服务器 IP，如果你打算用域名访问，就写域名。

7.3 基于 Nginx 反向代理的访问优化

如果你团队里有多套 Web 服务，不想每次都在 URL 里带端口号，可以用 Nginx 做反向代理。openEuler 上安装 Nginx 非常方便：

bash复制dnf install -y nginx

在 /etc/nginx/conf.d/gitblit.conf 里写：

nginx复制server {
    listen 80;
    server_name git.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

重启 Nginx 后，团队成员只要访问 http://git.example.com 就能打开 Gitblit，不需要记端口号。这个方案特别适合把 Gitblit 和其他内网工具（Jenkins、Nexus）统一收敛到 80 端口，给人一个统一的入口体验。注意 gitblit.url 要改成 http://git.example.com，避免克隆地址还是旧 IP 的尴尬情况。

8. 常见问题与排查技巧实录

8.1 openEuler 上部署 Gitblit 的 5 个高频问题

这里整理了一份我在部署和日常维护中遇到过的典型问题速查表：

8.2 进阶排查技巧

Jetty 日志打不开页面：如果 Gitblit 能启动，但页面空白或 404，先检查 jetty.log 里的 HTTP 状态码。如果出现 503 Service Unavailable，说明 Gitblit 的线程池或连接数满了，通常是同时并发访问过多导致。此时可以调大 jetty.threadPool.maxThreads 配置，但内网小团队场景基本不会遇到。

克隆大仓库时中断或超时：Gitblit 对 HTTP 协议的单次请求有超时限制，大仓库（几百 MB）首次克隆容易超时。可以在 gitblit.properties 里调大 http.requestTimeout，或者干脆让团队用 SSH 协议克隆，SSH 通道不经过 HTTP 中间层，稳定性更好。

如果 SSH 推送时提示 connection closed by remote host，大概率是用户没有 SSH 公钥，或者公钥格式不合法。Gitblit 只接受 OpenSSH 格式的公钥，如果你从 PuTTY 导出的公钥，需要先转成 ssh-rsa AAA... 的格式再导入。

8.3 从 CentOS 7 迁移到 openEuler 的注意事项

搜索词里有“centos7.5 应该使用 openeuler 哪个版本”，说明不少朋友是从老 CentOS 环境往 openEuler 迁移的。Gitblit 本身是 Java 应用，跨平台迁移非常平滑，核心注意点只有几个。

第一，CentOS 7 上默认用的可能是 Java 8，openEuler 的 Java 8 包名和路径不同（/usr/lib/jvm/java-1.8.0-openjdk 在两个系统上都类似，但实际安装来源不同），迁移时重新执行一遍 dnf install java-1.8.0-openjdk 并验证版本即可。

第二，CentOS 7 用 firewalld，openEuler 也是，端口放行命令完全一致，这一层不用重新学。

第三，迁移时直接把 /opt/gitblit/data 整个目录拷贝到新机器的对应路径下，gitblit.properties 里的 gitblit.url 改成新 IP，启动即可。数据文件的二进制兼容性很好，H2 数据库和 Git 仓库的格式与操作系统无关。

我实测过从 CentOS 7.9 迁移到 openEuler 22.03 的 Gitblit 1.9.3，整个过程没遇到任何数据格式问题，拷贝目录、改配置、启动，前后不超过十分钟。因此迁移不需要重装 Gitblit，也没有必要重建仓库。

9. 结合实际使用场景谈谈体会

Gitblit 在 openEuler 上的部署，本质上就是把几个成熟的组件拼起来：系统层面配置好网络和软件源，Java 提供运行时环境，Gitblit 作为开箱即用的 Git Web 管理端，再加上 systemd 做进程托管、tar 做备份。整条链路没有复杂的微服务架构，也没有分布式存储的夸张设计，但它就是能稳定运行，解决团队最核心的代码托管需求。

我在实际使用中的体会是，Gitblit 最大的优势不在于功能多，而在于“心智负担低”。GitLab 每次升级都让运维捏把汗，Gitea 虽然轻量但依赖了 Go 编译环境，Gitblit 就是一个 Java 进程加一个数据目录，出了问题你一个人用一根网线连上去就能定位和恢复。对于十人以下的小团队，这套方案完全够用。

最后说一个我踩过几次坑之后学到的技巧：Gitblit 升级时，不要直接删掉旧版本目录解压新包。正确的步骤是先把新包解压到新目录，然后把旧 data 目录复制过去，启动后用 Web 界面升级数据库迁移。这样即使升级失败，旧版本目录还在，可以立即回滚。Gitblit 的数据库迁移脚本成熟度不错，但给自己留一条后路永远是明智的。升级前把 /opt/gitblit 目录打个 tar 包，升级后先跑一天观察日志，没异常再清理旧目录。这个习惯让我不止一次从升级事故中全身而退。