简介：Gitblit 1.9.3 压缩包是一款面向 Java 技术栈团队的开源 Git 仓库管理工具，设计简洁直观、易上手，支持独立部署或嵌入 Java Web 应用，可完成仓库的创建、克隆、推送、拉取以及精细的权限访问控制，适合个人开发者与中小团队搭建私有 Git 服务。这份 RAR 包共 321 个文件、41.31MB，核心包含 75 个 jar 格式的 Java 库文件、11 个 Groovy 自动化脚本、8 个 Windows 命令脚本，以及由 35 个页面文件、24 个脚本文件、23 个样式文件组成的 Web 管理界面；包内还带有大量 gitignore、conf、properties 配置模板，覆盖仓库托管、用户权限、邮件通知等典型配置场景，可支撑安装部署、日常运维和二次开发。通过它，学习者可从零体验从解压、安装到配置的完整流程，掌握 Gitblit 的权限模型和仓库管理逻辑；附带的命令脚本与配置文件也能帮助初学者减少踩坑，直接投入实际项目使用。当前已有 347 人浏览/学习，适合正在搭建 Git 服务或需要统一管理团队代码权限的开发者参考使用。
1. 为什么还在用Gitblit：轻量级Git服务里的特殊存在
我先说个有意思的事：gitblit 这个老牌工具，居然时不时出现在热词榜上，而且经常是带着 "gitblit internal error" 一起出现的。这说明一个很现实的问题——真正在一线维护它的人，并没有想象中那么少。可能你接手了一台前辈留下的内网服务器，可能你所在的小团队不想为了一个内部代码库就引入庞大的 GitLab，也可能你只是想要一个开箱即用、不占内存的 Git Web 管理端。Gitblit 1.9.3 恰好就卡在这个需求点上。
1.1 一张表看清 Gitblit 和 GitLab、Gitea 的差别
很多人选型时容易犯一个错：拿 Gitblit 和 GitLab、Gitea 做全功能对比，比完之后觉得 Gitblit 这也缺那也缺，直接放弃。实际上它的定位根本不在同一个赛道。
| 对比维度 | Gitblit | Gitea | GitLab |
|---|---|---|---|
| 运行时依赖 | JDK + JGit | 单个二进制文件 | Ruby/PG/Redis/等一堆组件 |
| 内存占用 | 200~300MB 左右 | 50~100MB 左右 | 2GB起步很正常 |
| 安装复杂度 | 解压、改配置、启动 | 解压、启动 | 部署需要几步 |
| 内置 CI/CD | 支持 Groovy 钩子，但不是完整流水线 | 内置轻量 Actions | 完整 CI/CD 体系 |
| 代码审查 | 支持 Pull Request 模型 | 支持 PR | 完善 MR 流程 |
| 适用场景 | 内网小团队、临时交付、离线环境 | 中小团队、想长期维护的开源项目 | 企业级、需要完整DevOps |
Gitblit 最舒服的场景是"就是一个代码存放和权限管理工具"。它不会试图包办你的发布流程，也不会在某个版本升级后突然要求你迁移数据库。你把它部署好，告诉团队成员浏览器访问哪个地址，push/pull 就完事了。
1.2 1.9.3 这个版本的特殊性
Gitblit 1.9.3 是开发分支上比较稳定的一个版本，也是很多教程默认使用的版本。它基于 JGit 实现 Git 服务端逻辑，这意味着不需要在服务器上安装原生 Git 客户端，所有仓库操作都用 Java 层的 JGit 完成。
这带来一个隐藏好处：你不用担心服务器上 git 版本过老导致某些命令不兼容。但代价是 JGit 在极端场景下的容错率不如原生 Git，碰上仓库损坏或者fsck失败时，处理方式的思路会和传统 Git 服务器不太一样。这一点我会在后面专门展开。
另一个容易被忽略的点是：Gitblit 1.9.3 自带的 Web 界面虽然看起来朴素，但该有的都有，包括用户注册、仓库在线浏览、分支对比、提交历史、权限分配，甚至还有 Federation 联邦功能。对于纯粹想在内网快速搭建 Git 服务的人来说，这些功能恰恰是够用且不复杂的。
1.3 部署前需要想清楚的几个取舍
- HTTPS 和 HTTP：默认配置下 Gitblit 会以 HTTPS 方式自启动，端口 8443，并自带自签名证书。如果你在纯内网用，直接 https 访问就行，只是浏览器会提示证书不受信任，点过去即可。想改成 HTTP 访问，需要手动改配置。
- 内置 Jetty 还是外置 Tomcat：Gitblit 官方支持两种方式，一种是直接用
java -jar gitblit.jar跑内置 Jetty，另一种是部署 WAR 包。我建议绝大多数人用前者，少一层容器就少一层排查复杂度。 - 用户注册权限：首次访问 Web 界面时注册的第一个用户，会被自动赋予管理员权限。这一点很多人不知道，后续想重新分配管理员会绕一点弯路。
- 是否长期维护：Gitblit 项目本身更新速度不快，大版本演进也基本停在 1.9.x。如果你能接受"稳定但不再有新特性"这个状态，它完全够用；如果你想要活跃的社区和插件生态，那确实应该选 Gitea。想清楚这一点，后面遇到问题心态会稳很多。
2. 部署1.9.3的实际流程：内置Jetty一条路走到底
前面说了，这个工具的部署难度极低。下面是我在一台全新 CentOS 7 服务器上的完整操作记录，你照着走一遍，20 分钟内能访问到登录页。
2.1 环境准备：JDK选型与版本对应
Gitblit 1.9.3 基于 JGit，对 JDK 版本的要求不算苛刻，但也不要盲目上最新版。实测 Java 8 和 Java 11 都能稳定运行 1.9.3，Java 17 我遇到过某些自签名证书相关接口的兼容问题，所以稳妥起见，我推荐直接安装 OpenJDK 8：
yum install -y java-1.8.0-openjdk java -version如果你手头就是 Java 11，那也没问题，不用刻意降级。安装完 JDK 后，解压 Gitblit 包：
mkdir -p /opt/gitblit tar -zxvf gitblit-1.9.3.tar.gz -C /opt/gitblit --strip-components=1 cd /opt/gitblit目录结构大致是：gitblit.jar、data文件夹、docs文档目录、ext插件目录。所有运行时产生的配置、用户、仓库都会写在data目录里，这一条先记住，后面备份全靠它。
2.2 gitblit.properties里最值得改的几项
配置文件在data/gitblit.properties。先备份一份原始配置再改：
cp data/gitblit.properties data/gitblit.properties.bak需要关注的几个关键项，以我的使用经验为例：
# 仓库存放目录，默认是 data/git，可以改成独立数据盘 git.repositoriesFolder = /data/git-repositories # 服务端口，默认 8443 跑 HTTPS server.httpsPort = 8443 server.httpPort = 8080 server.securePort = 443 # 仓库的默认访问限制，建议一开始就收紧 # 0: 匿名可见 1: 仅登录用户可见 2: 开发者可查看 3: 完全私有 git.defaultAccessRestriction = 1 # Web 界面访问时的项目显示名称 web.siteName = My Git Server # 是否允许用户注册 web.allowLucene = true改完后启动服务：
./gitblit.sh start或者前台运行方便看日志：
java -jar gitblit.jar --baseFolder data启动成功后，浏览器访问https://服务器IP:8443就能看到登录页。
2.3 首次启动和验证
首次访问会有两个容易困惑的地方：
- 证书警告：因为用的是内置自签名证书，浏览器会提示"您的连接不是私密连接"。如果只是团队内网使用，点击"高级"然后继续前往即可。想彻底消掉警告，需要自己生成证书并配置到
server.keystore，这个属于进阶操作，我后面单独说。 - 注册第一个用户：Gitblit 初始状态下没有默认管理员账号。你注册的第一个用户会成为 Administrator。所以注册时名字要正经一点，团队里谁先注册谁就是管理员这个逻辑，很容易被忽略。
验证是否可用的最快方式是用命令行测试 HTTP 克隆：
git clone https://你的IP:8443/仓库名.git # 如果你的仓库还没创建，先在 Web 界面里 new repository能成功拉取，部署就算完成了。
2.4 我建议的HTTPS相关配置经验
很多内网环境根本没有外网域名，证书这个事很容易被忽略。我的做法是：在 Web 界面支持使用的前提下，直接把 HTTP 端口和 HTTPS 端口都打开，然后用 HTTP 做日常 clone/push，HTTPS 留给需要加密传输的管理操作。
修改如下：
server.httpPort = 8080 server.httpsPort = 8443这样团队成员用http://IP:8080/git/仓库名.git的地址访问，既避免了证书问题，又保留了加密通道。公网部署则建议反过来，只保留 HTTPS 并配置正规证书。
3. gitblit internal error深挖：一次由浅入深的排查案例
Gitblit 有个很出名的问题：页面操作报错时，往往只显示一个笼统的internal error，不告诉你具体是什么原因。很多搜到这个关键词的人，都是被这一句提示卡住的。其实这句话背后真正的问题是，Gitblit 把异常分类做得很粗糙，你需要自己从日志里找真正的原因。
3.1 报错出现的常见场景
根据我接触过的以及社区里高频出现的情况，internal error主要集中在以下几类操作：
- 在 Web 界面浏览某个仓库的提交记录或文件树
- 创建仓库或修改仓库描述
- 用户点击 fork 或提交 Pull Request
- 执行仓库的在线 GC（垃圾回收）
如果你在以上场景遇到错误，先不要慌，也不要急着去改配置文件。
3.2 第一手资料永远是 gitblit.log
Gitblit 的日志文件默认写在data/logs目录下，文件名通常是gitblit.log。用tail -n 100看到最近的异常堆栈，比在浏览器里面对internal error瞎猜要有用得多：
tail -n 200 /opt/gitblit/data/logs/gitblit.log | grep -A 50 "ERROR"看到具体的异常类型后，问题就好定位了。如果你的日志里只看到一行HTTP 500，没有堆栈信息，那就需要检查 logback 的配置，把日志级别调成DEBUG再看。
3.3 Case A：仓库损坏导致的 Internal Error
有一次我在 Web 界面打开一个项目，点击"tags"标签页时直接报了 internal error。日志里的核心异常是这类：
org.eclipse.jgit.errors.MissingObjectException: Missing unknown object ...这个报错的本质是：Git 仓库中有一个提交对象引用了并不存在的对象。常见触发原因是之前某次 push 中断、磁盘空间不足、或服务器异常断电导致对象没有完整写入。
处理思路如下，不需要删除仓库重新建：
# 1. 切换到该仓库目录 cd /data/git-repositories/项目名.git # 2. 用原生 git 做一次完整性检查 git fsck --full # 3. 如果有缺失对象，通过 gc 清理悬空引用 git gc --prune=now但注意一点：Gitblit 使用 JGit，而 JGit 对某些损坏的仓库容错度不如原生 Git。如果你在仓库目录下执行git fsck后依然报错，可以尝试用原生 git 把所有分支重新推送一份到临时仓库，然后把临时仓库替换掉原仓库：
git clone --bare /data/git-repositories/项目名.git /data/tmp-repo.git # 确认临时仓库正常后 mv /data/git-repositories/项目名.git /data/git-repositories/项目名.git.bak mv /data/tmp-repo.git /data/git-repositories/项目名.git这个处理方式基本能把对象层的问题修好，但仓库的权限配置、web hooks 等元数据不在这里，放心不会丢。
3.4 Case B：权限文件被改坏导致 Internal Error
还有一个高频原因和仓库损坏没关系，而是data目录下的权限配置文件格式出错。Gitblit 将用户、团队、仓库权限信息集中存储在配置文件中，如果手动编辑时多了一个特殊字符、换行错误或者中文引号写歪了，服务端解析就会失败，所有登录用户一操作就报 internal error。
日志里的典型表现是：
java.io.IOException: Failed to load users.conf遇到这种情况，最快的恢复方式是找回备份。如果你没有备份，就用文本编辑器仔细检查配置文件的引号、冒号、编码。需要特别注意 Windows 下用记事本编辑过的文件可能会把编码改成带 BOM 的 UTF-8，Java 读取时容易出问题。建议统一用 UTF-8 and LF 格式保存。
文件修好后重启 Gitblit：
./gitblit.sh restart或者先杀掉进程再启动，确保配置重新加载。重启后立刻登录 Web 界面，在用户管理页确认用户列表和权限是否恢复正常。
3.5 预防：把 Integrity Check 当成定期任务
这么多 Internal Error 类型里，真正可怕的是仓库对象损坏，因为它往往是安静发生的。Gitblit 1.9.3 自带一个git.gcExpression配置项，可以在特定时间触发 gc：
# 每天凌晨 3 点执行仓库垃圾回收 git.gcExpression = 0 0 3 * * ?定期 gc 能压缩对象、清理悬空引用，虽然不能百分百防止损坏，但能在问题演变成internal error之前把仓库状态理顺不少。另外，如果条件允许，我给生产环境加了一个简单的定时任务，每周跑一次git gc --prune=now，每月手动检查一次仓库大小变化，发现问题早处理，后面就不会被"疑似仓库损坏"这种问题搞得焦头烂额。
4. 团队协作中的真实用法：权限、HTTP与日常维护
部署好了，也学会了排障，接下来就要进入正式的日常管理。这一部分是我在管理几个小团队 Git 服务时沉淀下来的经验，不一定每个场景都适用，但对你理清 Gitblit 的使用习惯会有帮助。
4.1 用户/仓库/团队的权限模型
Gitblit 的权限逻辑其实很清晰，三条线：用户、团队、仓库。
- 用户：每个成员独立账号，注册后由管理员分配权限。
- 团队：把多个用户归为一组，比如
BackendTeam、FrontendTeam，给团队授权比单个用户授权省事得多，尤其是人员流动时。 - 仓库权限级别：从低到高包括查看、克隆、推送、强制推送等。管理员可以为每个仓库单独指定哪些用户或团队具有何种权限。
我的建议是，所有权限分配都尽量以团队为单位，不要给单个用户叠加过多仓库单独授权。否则一旦团队调整，清理权限会非常痛苦。
| 操作场景 | 建议权限 |
|---|---|
| 普通开发人员读取代码 | 查看 + 克隆 |
| 普通开发人员提交代码 | 查看 + 克隆 + 推送 |
| 需要重置分支的负责人 | 查看 + 克隆 + 推送 + 强制推送 |
| 管理员 | 全部权限 |
4.2 HTTP方式比SSH更适合内网
如果你之前管理过 GitHub/GitLab，可能会下意识想让 Gitblit 也提供 SSH 访问。Gitblit 支持 SSH，但实际用下来，内网场景我更推荐直接用 HTTP/HTTPS 方式。
原因有三点：
- 配置简单，不需要分发 SSH 公钥。用户只要在 Web 界面注册后，就能用账号密码方式 clone/push，省去把公钥交给管理员这一步。
- 内网传输速度足够快，HTTP 协议的开销几乎可以忽略。
- 排查问题方便，Gitblit 日志里有完整的 HTTP 请求记录，哪次 push 失败一眼就能看到。
常见且可用的操作：
# 用账号密码方式克隆 git clone http://192.168.1.100:8080/git/项目名.git # 首次 push 时记住凭据 git push origin master如果不想每次输入密码，可以配置 Git 凭据管理器，或者用 SSH 方式并建立密钥认证。这个看团队习惯，不强求。
4.3.gitignore和钩子脚本的补充
Gitblit 1.9.3 支持在仓库内配置.gitignore来忽略不必要的文件，同时也支持 Groovy 脚本的钩子机制。比如，在data/groovy/目录下放置post-receive.groovy，可以在每次 push 后触发通知脚本。这个功能很适合做简单的提交邮件提醒或自动部署触发。
不过我得提醒一句：不要过早引入复杂钩子。Groovy 脚本的执行环境和原生 Git 的 pre-receive hook 不太一样，调试起来比较费劲。我建议先让团队裸用 Gitblit 一两个月，确认基本流程稳定后再考虑添加钩子。
5. 数据安全：备份方式与迁移恢复的实际经验
Gitblit 的数据安全，在运维层面其实比很多同类工具更简单，因为它所有东西都在一个data目录里。但正因为简单，很多人会误以为"只要仓库目录还在就够了"，结果恢复时才发现用户权限全丢了。
5.1 只有"复制整个数据目录"才算备份完整
我刚开始管理 Gitblit 时，只把data/git目录做了定时备份，因为潜意识里觉得代码库才是最重要的。直到有一次服务器磁盘故障，恢复后发现所有仓库都在，但用户列表、团队授权、仓库描述全没了，等于要从头搭建权限模型，那一刻才意识到问题严重。
正确的做法是整个data目录一起备份。它至少包含：
data/git/：仓库存储data/users.conf：用户账号信息data/teams.conf：团队信息data/gitblit.properties：服务配置data/logs/：运行日志
最简单的备份命令：
tar -czvf /backup/gitblit-backup-$(date +%Y%m%d).tar.gz /opt/gitblit/data如果是 Windows 环境，直接复制data文件夹到备份盘也可以，但最好先停掉 Gitblit 服务或确认没有正在进行的 push，防止文件被占用或写入一半。
5.2 从备份恢复或迁移的过程
恢复其实更简单。在新的机器上装好同样的 Gitblit 1.9.3，把data目录整个覆盖过去，再启动服务即可。需要注意两点：
- 新机器的 JDK 版本尽量和原机器保持一致，避免 JGit 版本差异带来意外问题。
- 如果服务地址变了，仓库里克隆地址会失效，团队成员的
origin需要重新设置。这种情况建议提前通知大家改地址。
我经历过一次跨机房迁移，做法是：先在新机器上启动一次 Gitblit 生成默认data目录，然后停掉服务，用备份包直接覆盖，再启动。整个过程零丢数据，用户登录状态、权限、仓库都原样恢复。
5.3 几个容易被忽略的备份细节
- 备份前先做一次仓库 GC：压缩仓库体积能明显减少备份时间和磁盘占用。在 Web 界面或命令行执行
git gc后再打包。 - 备份期间要防止并发写入：尤其是业务高峰期，尽量把备份任务放在凌晨或非工作时间。
- 配置文件里不要写死服务器 IP：迁移到新机器时会被地址问题绊一脚。推荐的写法是让管理员在 Web 界面里设置项目的访问地址，底层配置保持相对路径。
- 验证备份是否可恢复：偶尔在测试机恢复一次，别等到灾难发生时才发现备份文件是坏的。我在之前一个项目中吃过亏，备份跑了一年，恢复时才发现打包时漏了
data/logs目录，虽然仓库没丢，但要看历史操作记录时就傻眼了。
维护 Gitblit 这类轻量工具，我个人最大的感受是：它不需要你投入太多精力，但也不能完全放着不管。定期看一眼磁盘空间和日志，备好整个 data 目录，就已经能应对绝大多数生产问题了。如果你也接手了一台跑着 Gitblit 的旧服务器，别急着换系统，先按上面的思路把备份和日志完善起来，它还能安安稳稳地服务好几年。
本文还有配套的精品资源，点击获取
