简介Gitblit-1.9.3 是一款面向 Java 开发团队与运维人员的开源 Git 仓库管理工具可独立运行也能嵌入其他 Java Web 应用帮助团队完成仓库创建、权限分配、克隆推送与访问控制等日常版本控制工作。资源包共 321 个文件约 41.31MB以 75 个 jar 核心依赖、35 个 html 页面、24 个 js 与 23 个 css 前端资源为主另含 105 个 gitignore 模板、11 个 groovy 脚本及若干 cmd 启动脚本、conf 配置文件和 properties 国际化资源覆盖服务安装、索引重建、票据迁移等运维场景。目前已有 352 人学习下载。解压后可按文档完成仓库存储位置、访问权限与 SMTP 邮件通知等配置适合需要自建 Git 服务、精细控制用户与用户组权限的中小团队参考使用。1. 从一台内网旧服务器说起gitblit-1.9.3 到底能解决什么很多团队都遇到过这种局面一台配置不高、系统版本偏旧的内网服务器跑不动 GitLab 那种重型平台但代码又必须集中托管、要能看提交历史、要能分配权限、还要能出仓库列表。这时候 gitblit-1.9.3 就是一个很务实的选择。它是一个用 Java 写的轻量级 Git 服务端单个 jar 包就能启动自带 Web 界面支持仓库浏览、用户与团队权限、HTTP 与 SSH 两种拉取方式对内存和 CPU 的要求比同类平台低一大截。它适合谁适合内网小团队、实验室、教学环境以及那些只想安安静静托管几十个仓库、不想维护数据库和一堆中间件的场景。这一版 1.9.3 属于 1.9.x 分支的后期版本稳定性和兼容性都经过了不少实际部署的检验下面我就按自己拆包、部署、踩坑的顺序把这份资源怎么落地讲清楚。2. 拆开 gitblit-1.9.3目录结构、运行依赖与选型理由拿到 gitblit-1.9.3 的包之后别急着双击启动先花几分钟把目录看明白后面排错会省很多事。它的结构不复杂但每一块都有明确分工理解之后你改配置、迁数据、做备份都会心里有数。2.1 目录里都有什么哪些能改哪些别动解压后典型的结构是这样的不同打包方式可能略有差异但核心一致路径作用是否建议改动gitblit.jar主程序所有逻辑都在里面不动data/默认数据目录含配置、仓库、用户库可迁移建议独立挂载data/gitblit.properties主配置文件必须按环境改data/defaults.properties默认值升级时会被覆盖不改改主配置data/repositories/实际 Git 仓库存储位置可迁移到大盘data/users.conf用户与权限定义按需改ext/放 JDBC 驱动、插件等扩展按需放service/各系统服务安装脚本部署时用这里有个血泪经验defaults.properties是官方默认值升级版本时会被新包覆盖你所有自定义项都必须写在gitblit.properties里否则升级一次配置全丢。我一般会把data/整个目录单独放到一块数据盘上用软链接指回去这样换 jar 包不影响仓库和用户数据。2.2 运行依赖JDK 版本和内存怎么定gitblit-1.9.3 是 Java 应用运行前确认 JDK 已装好。它兼容 JDK 8 及以上但如果你用的是 JDK 11 之后的版本注意启动脚本里有些旧参数可能不认需要手动调整。检查命令很简单java -version输出里能看到版本号即可。内存方面默认启动脚本给的堆不大仓库多了或者并发克隆频繁时容易卡。我一般会在启动参数里显式指定# 在启动脚本中调整 JVM 内存-Xmx 按机器实际内存给 java -Xms256m -Xmx1024m -jar gitblit.jar --baseFolder data-Xms是初始堆-Xmx是最大堆。内网几十个仓库、十来个人用1G 足够如果仓库体积大、历史深建议给到 2G。--baseFolder指定数据目录这是最关键的参数不写它默认用当前目录下的data迁移时容易搞错。2.3 为什么选它而不是更重的方案选型理由说白了就三条第一零外部数据库依赖用户和权限默认走文件存储省掉一个维护点第二单进程启动没有一堆后台服务要盯着第三Web 界面够用仓库浏览、提交历史、分支对比、权限分配都有不追求 CI/CD 那种全家桶。如果你的需求只是「内网有个地方放代码、能看能管」那 gitblit-1.9.3 的投入产出比很高。反过来如果你需要内置流水线、容器镜像仓库、复杂合并请求流程那它就不合适别硬上。3. 把 gitblit-1.9.3 跑起来配置、启动与首个仓库这一章是动手部分按顺序走基本能一次点亮。中间涉及配置文件修改、启动方式选择、仓库创建和权限分配每一步我都把参数含义说清楚方便你按自己环境改。3.1 主配置文件里必须改的几项打开data/gitblit.properties下面这些项建议逐条确认# Web 服务监听端口默认 8080被占用就换 server.httpPort 8080 # 对外访问地址影响克隆链接的生成内网写实际 IP 或域名 server.httpBindInterface 0.0.0.0 web.canonicalUrl http://192.168.1.10:8080 # 仓库存储根目录建议指向大盘 git.repositoriesFolder /data/gitblit/repositories # 是否允许匿名浏览内网可开公网务必关 web.allowAnonymousAccess false # 用户与权限文件位置 realm.userService /data/gitblit/users.confweb.canonicalUrl这项特别容易被忽略它决定了 Web 界面上显示的克隆地址。如果这里写的是localhost别人从自己机器上复制链接就克隆不了现象是「链接看着对一拉就超时」其实就是地址生成错了。web.allowAnonymousAccess建议关掉哪怕内网也别图省事权限这东西开了口子就难收。3.2 启动方式前台试跑和服务化第一次部署先用前台方式跑方便看日志# 前台启动日志直接打到终端适合首次验证 java -Xms256m -Xmx1024m -jar gitblit.jar --baseFolder /data/gitblit看到日志里出现 Web 服务启动、端口监听的提示就可以用浏览器访问http://你的IP:8080。默认管理员账号是admin密码也是admin第一次登录后立刻改掉这是基本操作。验证没问题后再用service/目录下对应系统的脚本注册成系统服务让它开机自启、后台运行。注册前记得把脚本里的 jar 路径和 baseFolder 改成你的实际路径否则服务起不来还找不到原因。3.3 建第一个仓库并分配权限登录后进 Web 界面创建仓库的流程不复杂但有两个点要注意。一是仓库名称建议用英文加短横线避免中文和空格虽然它支持但在某些 Git 客户端和脚本里容易出编码问题。二是创建时可以选择「裸仓库」还是带工作区服务端一律用裸仓库这是规范。创建完仓库进权限设置页把用户或团队加进去。gitblit 的权限模型是「仓库级 团队级」常见做法是建几个团队比如dev、readonly把用户归到团队里再给团队授仓库权限这样人多了也不用一个个配。权限项里RW是读写R是只读RWC还包含创建分支等操作按角色给就行。克隆验证# 用 HTTP 方式克隆会提示输入用户名密码 git clone http://192.168.1.10:8080/git/demo.git # 如果配了 SSH也可以用 SSH 方式 git clone ssh://git192.168.1.10:29418/demo.gitHTTP 方式最省事不用配密钥SSH 方式适合频繁操作、不想每次输密码的场景但需要在用户设置里上传公钥并且确认 SSH 端口没被防火墙挡。克隆成功、能提交能推送这套服务就算真正跑通了。4. 避坑与排查gitblit-1.9.3 部署中最容易翻车的几处这一章是我自己踩过、也帮别人处理过的典型问题按「现象 → 原因 → 解决」写遇到对应情况直接对号入座。4.1 启动报端口被占用现象执行启动命令后立刻退出日志里出现Address already in use。原因8080 端口被别的进程占了或者上一次没退干净。解决先查占用进程netstat -tlnp | grep 8080或ss -tlnp | grep 8080确认后要么停掉那个进程要么在gitblit.properties里把server.httpPort改成别的端口重启即可。4.2 克隆地址是 localhost 导致别人拉不了现象本机访问正常同事复制界面上的克隆链接却连不上。原因web.canonicalUrl没改还是默认的 localhost。解决改成服务器实际内网 IP 或域名重启服务。改完最好清一下浏览器缓存再刷新界面确保链接重新生成。4.3 仓库目录迁移后仓库列表空了现象把repositories目录挪到大盘改完配置重启Web 上仓库全没了。原因多半是git.repositoriesFolder路径写错或者新目录权限不对服务进程读不到。解决确认配置里的路径是绝对路径且运行服务的用户对该目录有读写权限ls -l看一眼属主必要时chown修正。改完重启仓库会自动重新扫描出来。4.4 大仓库克隆中途断开现象克隆一个历史很深的仓库跑到一半报连接重置。原因JVM 堆偏小或者 HTTP 超时设置太短。解决先把-Xmx调大再检查配置里和超时相关的项适当放宽。另外内网带宽如果一般建议错开高峰克隆别几个人同时拉大仓库。4.5 升级后自定义配置丢失现象换了新版本的 jar 包之前改的端口、路径全变回默认了。原因改动写进了defaults.properties升级时被覆盖。解决所有自定义项只写在gitblit.properties升级前备份data/整个目录升级后只替换 jar 和必要的脚本数据目录原样保留。养成这个习惯升级基本无痛。5. 进阶技巧备份、迁移与日常维护的固定动作跑通只是开始真正让这套服务省心的是后面这些固定动作。我一般会做三件事定时备份、定期看日志、迁移前先演练。备份的核心就是data/目录里面包含配置、用户、仓库三样命根子。仓库本身是 Git 仓库理论上可以靠git clone --mirror逐个备份但仓库多了太麻烦直接打包目录最省事。我习惯用一条带日期的打包命令配合计划任务每天跑一次# 打包 data 目录排除临时文件按日期命名 tar -czf /backup/gitblit-$(date %Y%m%d).tar.gz \ --exclude*.tmp \ -C /data gitblit-C /data gitblit表示切到/data再打包gitblit目录这样解压出来路径干净。保留最近若干天的包旧的自动清理别让备份把磁盘撑满。迁移到新机器时顺序很重要先在新机器装好同版本 JDK把备份包解压到相同路径确认gitblit.properties里的路径和 IP 改成新机器的再启动。启动后先别急着让人用自己克隆一个仓库验证读写确认无误再切流量。这个「先验证再开放」的习惯帮我避免过好几次迁移后才发现权限或路径不对的尴尬。还有一个日常技巧是看日志定位问题。gitblit 的日志会记录访问、认证失败、仓库操作等信息遇到「某人说推不上去」先看日志里对应时间点有没有认证失败或权限拒绝的记录比盲目猜快得多。日志级别可以在配置里调平时用默认排查时临时调细查完记得调回去不然日志涨得飞快。从那以后我每次部署这类轻量服务都强制走一遍「前台试跑 → 克隆验证 → 备份脚本 → 迁移演练」的流程不跳步。希望帮到你。本文还有配套的精品资源点击获取