简介Gitblit-1.9.3 是一款开源 Git 仓库管理工具面向需要自建代码托管服务的开发团队与运维人员可独立运行或嵌入 Java Web 应用提供仓库创建、克隆、推送、拉取及细粒度权限控制等全流程支持。该版本在界面体验、性能与安全性上有所改进并修复了早期版本的若干缺陷。资源包共 321 个文件约 41.31MB以 jar 核心库、html 页面、js 与 css 前端资源、png 图标、groovy 脚本及 cmd 启动脚本为主另含 conf 配置、properties 与多语言模板文件覆盖服务安装、索引重建、权限配置等模块。已有 352 人学习下载。解压后可按文档完成仓库存储位置、访问权限与邮件通知等配置适合团队协作场景下进行版本控制与权限分级管理。1. gitblit-1.9.3一台老版本 Git 服务为什么还在内网活着很多团队第一次接触 gitblit-1.9.3不是因为想用它而是因为接手了一台跑了好几年的内网服务器。上面挂着几十个仓库Web 界面还能打开但没人敢动它——升级怕崩重启怕起不来迁移又不知道从哪下手。gitblit 这个用 Java 写的轻量级 Git 服务在 1.9.3 这个版本上停留的团队特别多原因很现实它够小、够稳、单机就能跑不需要数据库集群一个 jar 包加一份配置文件就是全部家当。这篇文章面向的是正在维护或准备部署 gitblit-1.9.3 的运维和开发人员。我会把版本选型、目录结构、配置参数、仓库迁移、重启排查这几件事讲透让你能在一台干净的机器上把它跑起来也能在它出问题时知道先看哪个日志、改哪个参数。gitblit 重启是搜索里出现频率很高的词说明大量问题都集中在服务生命周期管理上这部分我会单独用一章拆开讲。2. 把 gitblit-1.9.3 跑起来环境、目录与最小启动命令2.1 为什么是 1.9.3 而不是更新的版本gitblit 的版本线在 1.9.x 之后有过比较大的调整1.9.3 属于这个系列里相对成熟的一个点。选它的常见理由有三个一是依赖的 Java 版本要求不高JDK 8 就能跑很多内网服务器上装的就是 JDK 8二是配置文件格式稳定网上能找到的配置示例大多基于这个版本照着改不容易踩格式坑三是它的 GO 脚本和批处理脚本在 Linux 和 Windows 上都能用不需要额外装构建工具。如果你现在要新部署一套内网 Git 服务且服务器环境受限、不想引入 Docker 和数据库gitblit-1.9.3 仍然是一个可选项。但要注意它的 Web 界面和 API 能力比现代 Git 平台弱不少适合仓库数量在几百以内、以只读浏览和简单权限控制为主的场景。2.2 目录结构先认清 data 和 baseFoldergitblit 解压后有几个关键目录搞混它们是最常见的翻车起点。目录/文件作用是否要备份data/存放gitblit.properties、users.conf、projects.conf等配置必须data/git/默认的仓库存储根目录每个仓库一个子目录必须data/ssh/SSH 密钥和 host key建议data/tickets/工单数据如果启用了 tickets按需ext/外部 jar 和插件按需gitblit.jar主程序否baseFolder这个参数决定了 gitblit 去哪里找配置和仓库。默认情况下它指向data/但如果你用启动脚本传了--baseFolder实际路径会变。排查问题时第一件事就是确认当前进程用的 baseFolder 到底是哪个。2.3 最小启动一条命令跑起来在 Linux 上最直接的启动方式是用自带的脚本# 进入 gitblit 解压目录 cd /opt/gitblit-1.9.3 # 用默认配置启动前台运行方便看日志 java -jar gitblit.jar --baseFolder data如果想让它在后台跑可以用nohup或者自带的gitblit.sh# 后台启动并把日志写到指定文件 nohup java -jar gitblit.jar --baseFolder data /var/log/gitblit.log 21 # 确认进程和端口 ps -ef | grep gitblit ss -lntp | grep 8443默认情况下 gitblit 会监听 8443HTTPS和 8080HTTP具体取决于gitblit.properties里的server.httpPort和server.httpsPort。第一次启动后用浏览器打开http://服务器IP:8080默认管理员账号是admin密码也是admin登录后第一件事就是改密码。提示JDK 8 环境下启动如果报Unsupported major.minor version说明 jar 是用更高版本编译的换 JDK 8 或升级 JDK 即可不要硬改 jar。3. gitblit.properties 里必须改对的几个参数3.1 仓库根目录与 baseFolder 的关系gitblit.properties里有一个git.repositoriesFolder参数它决定了仓库实际存在哪里。很多人以为改了baseFolder仓库就会跟着走其实不是。# 仓库存储根目录可以是绝对路径 git.repositoriesFolder /data/git-repos # 服务监听端口 server.httpPort 8080 server.httpsPort 8443 # 对外访问地址影响克隆 URL 的生成 web.canonicalUrl http://git.internal.example.com:8080git.repositoriesFolder如果写成相对路径是相对于baseFolder解析的。生产环境建议写绝对路径并且这个目录要单独挂盘或单独备份。web.canonicalUrl决定了 Web 界面上显示的克隆地址如果配错用户复制出来的 URL 就是错的克隆会直接失败。3.2 用户与权限users.conf 和 projects.confgitblit 的用户体系不依赖数据库全部落在users.conf里。每个用户一段配置密码是 SHA-1 加盐后的摘要。# users.conf 片段 [user] username zhangsan password sha1摘要 displayName 张三 emailAddress zhangsanexample.com权限控制通过projects.conf和仓库级别的access配置完成。常见做法是建一个developers团队给团队分配仓库的 push 权限个人账号加入团队。改完users.conf后不需要重启gitblit 会定期重载但为了保险改完等十几秒再验证。3.3 邮件通知与工单按需开启gitblit 支持邮件通知和内置工单。如果内网没有 SMTP 服务邮件通知直接关掉否则日志里会不断刷连接超时。# 关闭邮件通知 mail.server mail.enabled false # 工单功能不用就关 tickets.service com.gitblit.tickets.NullTicketService工单服务如果开着但没配数据库默认用的是文件存储仓库多了以后tickets/目录会膨胀。不用工单的团队建议直接关掉减少一个故障点。4. 仓库迁移与备份把 gitblit 重启风险降到最低4.1 冷备份停服务再打包gitblit 的仓库就是标准的裸仓库理论上可以直接复制。但运行中复制有风险可能拿到不一致的 refs。稳妥做法是停服务再打包。# 停掉 gitblit 进程 kill $(pgrep -f gitblit.jar) # 打包配置和仓库 tar czf gitblit-backup-$(date %F).tar.gz \ /opt/gitblit-1.9.3/data \ /data/git-repos # 确认没有残留进程 pgrep -f gitblit.jar || echo 已停止打包完成后可以重新启动服务。恢复时把data/和仓库目录解回原位注意文件属主要和运行 gitblit 的用户一致否则会出现仓库不可读。4.2 单仓库迁移用 git clone --mirror如果只是迁移某几个仓库到另一台 gitblit不需要整机搬。# 从旧服务克隆裸仓库 git clone --mirror http://old-server:8080/r/demo.git demo.git # 推到新服务 cd demo.git git push --mirror http://new-server:8080/r/demo.git--mirror会连 refs、标签、分支一起带过去。推之前要在新服务上先建好同名仓库或者确认新服务允许自动创建仓库。推完后到新服务的 Web 界面确认提交历史和分支数量对得上。4.3 迁移后必须检查的三件事第一检查web.canonicalUrl是否指向新地址否则克隆 URL 还是旧的。第二检查users.conf里的账号是否都迁过来了尤其是服务账号和 CI 用的账号。第三检查仓库的access权限团队和个人的授权关系不会自动跟着仓库走需要在新服务上重新配。注意迁移完成后不要急着删旧服务保留至少一周只读访问方便回滚和对比。5. gitblit 重启相关的避坑与排查5.1 重启后 8443 端口起不来现象执行启动命令后进程在但ss -lntp看不到 8443Web 打不开。原因8443 端口被其他进程占用或者server.httpsPort配成了已被占用的端口。另一个常见原因是 keystore 文件路径不对或密码错误gitblit 在初始化 HTTPS 时失败但进程没有立刻退出。解决先看日志里有没有Address already in use或Keystore was tampered with。端口占用就换端口或停掉占用进程keystore 问题就检查server.keystorePath和server.keystorePassword必要时用keytool重新生成。5.2 重启后仓库列表为空现象服务起来了登录也正常但仓库列表是空的。原因git.repositoriesFolder指向的路径变了或者挂载盘没挂上。也可能是baseFolder传错导致读的是另一份配置。解决在 Web 界面看系统设置里的repositoriesFolder实际值和预期对比。如果是挂载盘问题先确认df -h里盘在不在再重启服务。5.3 重启过程中用户正在 push现象重启后某个仓库的 push 失败或者仓库出现index.lock。原因gitblit 重启时如果有 push 正在进行可能留下锁文件或未完成的 ref 更新。解决到仓库目录下检查有没有index.lock确认没有 git 进程在跑之后删掉锁文件。然后让用户重新 push。预防办法是重启前在负载均衡或防火墙上摘掉流量等几分钟再操作。5.4 日志文件暴涨把磁盘写满现象服务运行一段时间后磁盘满gitblit 无法写入。原因默认日志级别是 INFO访问量大时日志增长很快且没有自动轮转。解决在gitblit.properties里调高日志级别或配置轮转。# 只记录警告以上 log4j.logger.com.gitblitWARN # 如果用的是 logback 或外部配置按对应格式配轮转同时用系统的logrotate对 gitblit 日志做每日轮转保留 7 天。5.5 重启后 SSH 克隆报 host key 错误现象重启后用户用 SSH 克隆提示 host key 验证失败。原因data/ssh/下的 host key 在重启时被重新生成或者迁移时没带过来。解决把备份里的data/ssh/恢复回去保持 host key 不变。如果确实需要重新生成提前通知用户更新 known_hosts。6. 用 systemd 管住 gitblit 重启再配一个健康检查把 gitblit 交给 systemd 管理是减少重启玄学最有效的一步。下面这个 unit 文件我用了很久关键是Restart和RestartSec两个参数。# /etc/systemd/system/gitblit.service [Unit] DescriptionGitblit Git Service Afternetwork.target [Service] Typesimple Usergitblit Groupgitblit WorkingDirectory/opt/gitblit-1.9.3 ExecStart/usr/bin/java -jar /opt/gitblit-1.9.3/gitblit.jar --baseFolder /opt/gitblit-1.9.3/data Restarton-failure RestartSec10 StandardOutputappend:/var/log/gitblit/stdout.log StandardErrorappend:/var/log/gitblit/stderr.log [Install] WantedBymulti-user.targetRestarton-failure表示进程异常退出时自动拉起正常systemctl stop不会触发。RestartSec10给端口释放留出时间避免刚挂就重启导致端口占用。User和Group要提前建好并且对data/和仓库目录有读写权限。配好之后systemctl daemon-reload systemctl enable gitblit systemctl start gitblit systemctl status gitblit健康检查不用太复杂定时请求一下 Web 端口就行# 每 5 分钟检查一次失败就记录 */5 * * * * curl -sf -o /dev/null http://127.0.0.1:8080/ || echo $(date) gitblit health check failed /var/log/gitblit/health.log这个检查只验证 HTTP 端口能响应不验证仓库读写。如果要更严格可以加一个只读账号定时用git ls-remote拉一下某个仓库的 refs能返回就说明服务正常。我自己的习惯是任何一次改配置或升级之前先手动跑一遍备份脚本确认备份文件能解开、仓库数量对得上再动服务。gitblit 这种老服务后悔药就是备份没有别的。希望帮到你。本文还有配套的精品资源点击获取