简介：Gitblit 1.9.3 是面向Java技术栈团队的开源Git仓库管理工具，适合需要自建代码托管平台、精细控制成员读写权限的开发者或运维人员。这份安装包共含321个文件，以jar程序库、gitignore规则文件、html/css/js界面资源为主，另有cmd/exe服务脚本、conf配置模板及groovy扩展点等，整体包体41.31MB，解压后即可按官方文档部署为独立服务或嵌入现有Web应用。已有352人学习下载。借助该版本可快速搭起仓库创建、克隆、推送、拉取及用户组权限分配等日常管理能力；包内附带服务安装/卸载脚本、SSH服务说明和权限样例配置，对希望梳理Gitblit部署细节、排查常见配置问题或定制项目权限模型的读者尤为实用。整体结构简洁，适合中小团队用作代码版本集中管控的轻量方案。
1. 从 Gitblit 1.9.3 说起：为什么还在用这个“老家伙”
团队内部要搭一套 Git 服务端，很多人第一反应是 GitLab。但 GitLab 那套对内存的胃口实在不小，2G 内存的云主机跑起来都吃力，更别说一堆 Java 进程在后台互相打架。Gitblit 1.9.3 是另一种选择——一个自带 Web 界面的 Git 服务器，打包成 WAR 或独立服务，装上一跑，瞬间得到一个带权限管理、仓库浏览、在线代码查看的 Git 服务端。这名字看着老，可它解决的从来不是“酷不酷”的问题，而是“给团队给一个能用的 Git 服务器要花多少成本”的问题。
常见做法是把 Gitblit 跑在内网服务器上，配好 SSH 和 HTTP 访问，给每个项目建好仓库，再按开发者角色分配读写权限。Gitblit 1.9.3 是 2020 年前后的稳定版本，用 Java 8 就能跑，配置文件是你编辑的gitblit.properties，数据存在一个data目录里，随手打包就能备份。这篇文章里，我会从头到尾把 Gitblit 1.9.3 的部署、仓库创建、权限配置、备份和最常翻车的几个地方讲一遍，讲的全是我自己复制粘贴跑过的命令和改过的配置。
适合谁读？一句话：你被 GitLab 吃内存搞到头大，或者团队只有十来个人、不想搞 Kubernetes 那套东西，只想要一个打开浏览器就能用、权限逻辑是“读不到仓库就看不到列表”的 Git 服务端，Gitblit 1.9.3 会是很顺手的替代品。
2. Gitblit 1.9.3 的部署选型：独立服务还是 WAR 包
2.1 先看 Gitblit 1.9.3 的核心概念：仓库、用户、团队、权限
在动手装之前，得先把 Gitblit 的四个基本概念划清楚。仓库（repository）就是你推代码的地方，可以是普通仓库，也可以是镜像仓库；用户（user）是一个能登录、能操作仓库的账号，密码可以存在配置里指定的文件或数据库里；团队（team）是用户的分组，权限大体上能分配给团队，这样新成员只要加进团队，就自动拿到了所有该有的访问权，不用一个个仓库去勾选。
权限模型是 Gitblit 最值得琢磨的地方。它给每个仓库设了四种动词权限：查看（View）、克隆（Clone）、推送（Push）、创建引用（Create Ref）。而每个访问者会被归为匿名用户（Anonymous）、已认证用户（Not Federated）、管理员（Admin）中的一类。安全设置里的web.allowCompare这类开关控制的是“能不能看到远程仓库地址”，git.enableGitServlet负责 HTTP 智能协议是否启用。这种设计意味着什么？匿名用户能看到多少，完全由你在授权文件里配了哪些“条目”决定。很多人在这一步栽过：以为设了密码就安全了，结果匿名克隆还是能发生，因为downloads.requireAuthentication和相关*.*授权没关。
2.2 独立服务模式：最小化部署命令
最常见的部署方式是独立服务模式。去 Gitblit 官网下载gitblit-1.9.3.zip，解压到/opt/gitblit下，目录里有一个gitblit.jar、一个data目录、一个ext目录，还有一个gitblit.properties。启动方式是先设置一个环境变量GITBLIT_HOME，指向这个解压根目录，这样程序才知道去哪读配置。
export GITBLIT_HOME=/opt/gitblit cd $GITBLIT_HOME java -jar gitblit.jar --baseFolder $GITBLIT_HOME/data--baseFolder参数指定数据目录，所有仓库、用户配置和权限文件都放这里。启动后默认监听端口是8443，因为 Gitblit 默认使用 HTTPS。如果你只想在局域网环境里快速跑起来，可以直接把server.httpPort改成8080，把server.httpsPort设为-1停掉 HTTPS，免得跟证书纠缠。命令行的意思是：先设好根目录，再让 jar 启动，Jetty 服务会读取data里的配置。第一次启动时data目录会生成一堆默认文件，users.conf里会有一个默认管理员账号admin，密码在日志里打印出来，登录之后必须立刻改掉。
2.3 WAR 部署模式：适合已有 Tomcat 的环境
如果公司已经有 Tomcat，不想多维护一个 Java 服务，那用 WAR 部署更省事。把gitblit-1.9.3.war丢进 Tomcat 的webapps目录，启动 Tomcat 后它自己会解压部署。但有一点要注意，WAR 模式下你必须在 Tomcat 的 Java 系统属性里加上gitblit.home，否则 Gitblit 会在当前用户目录下乱建数据目录，到时候找仓库位置能找到你怀疑人生。
export CATALINA_OPTS="-Dgitblit.home=/data/gitblit-data" catalina.sh run这段是给 Tomcat 设置gitblit.home的常用办法，CATALINA_OPTS里加系统属性，指向你的数据目录。注意，如果你不改这步，Tomcat 重启以后 Gitblit 可能找不到之前的仓库。我一般会选择独立服务模式，因为隔离性好——Tomcat 升级或崩了不会牵连 Gitblit，Gitblit 升级也就是换个 jar 的事。
server.httpPort、server.httpsPort、server.httpsBindInterface这组参数控制了服务监听的端口与网卡。内网生产环境里，我通常关闭 HTTP，只留 HTTPS，并在 Nginx 层做 TLS 终止，让 Gitblit 只面对内网流量。这样外网碰不到 Jetty，就少了一堆扫描攻击的杂音。
3. 配置gitblit.properties：三个必调的参数组与内置权限模型
3.1 必调参数一：网络与端口绑定
安装完成之后第一件事不是建仓库，而是打开gitblit.properties把下面这组参数改一遍。默认配置对本地测试没问题，但放在真实服务器上就必须调整。
# 必调：HTTP 与 HTTPS 端口 server.httpPort = 8080 server.httpsPort = 8443 server.httpBindInterface = 0.0.0.0 server.httpsBindInterface = 0.0.0.0 # 推荐的仓库根目录 git.repositoriesFolder = ${baseFolder}/git # 关闭不需要的 RPC 功能避免暴露信息 git.enableRpc = false参数含义很直白：server.httpPort是普通 HTTP 服务的端口，server.httpsPort是 HTTPS 端口，git.repositoriesFolder是仓库存储根目录。这里有个小而关键的坑：如果你改了server.httpPort而忘了设server.httpBindInterface，很可能绑定错了网卡导致外部访问不了。所以显式写成0.0.0.0监听所有网卡是最省心的做法。做完修改，需要重启 Gitblit 进程才能生效。
3.2 必调参数二：用户认证与用户管理员
Gitblit 默认的用户配置存储在users.conf，这是一个类 JSON 的格式。认证方式可以在git.authentication里设置，常见的有local和ldap。小型团队用local就够了，麻烦的是维护成本，但只要人少，这个方案最稳定。
git.authentication = local git.defaultAccessLevel = VIEW web.allowGravatar = falsegit.authentication=local表示用户信息全部走本地文件，不定数据库也不需要额外服务。git.defaultAccessLevel控制一个新用户或新仓库创建后，默认有什么权限。把它设成VIEW，意味着匿名用户对新建仓库默认只有查看的权限，不会有克隆或推送权限，这是个保守但正确的默认值。web.allowGravatar关掉，头像不从外部加载，内网部署的加载速度快一截，也不向外部泄露内部邮箱的 MD5。
用户管理员这个配置藏在web.allowFlash这种旧开关旁边，容易被忽略。真正关键的是realm.userService的实现：默认users.conf是文件用户服务，指定用org.eclipse.jgit.util.StringUtils那套不现实。我常用的做法是在users.conf里给每个用户指定role = [ "#admin" ]来授予管理员权限，#admin是一个隐含角色，跟团队无关，就是字面意思的“管理员”。
3.3 必调参数三：仓库浏览与 HTTP 智能协议
需要调的第三组参数是git.enableGitServlet和web.enableKibble之类的配置。git.enableGitServlet必须保持true，否则 Git 客户端通过 HTTP 克隆会直接失败，一脸茫然。web.enableKibble这个参数是用来统计用户、仓库、提交数据的，如果不需要可以在配置里保持默认，不要乱开。真正需要仔细配的是git.enableGitServlet与 Nginx 代理路径的组合，如果你把 Gitblit 挂在 Nginx 下，得给 location 加上proxy_pass http://127.0.0.1:8080;，还要配好proxy_set_header。
git.enableGitServlet = true web.enableKibble = true web.allowHttp = true git.sshPort = 29418这里git.sshPort默认是29418，不是 22。因为 22 端口通常被系统 SSH 服务占用，Gitblit 选择了一个非特权端口来跑自己的 SSH 服务。团队里如果不习惯用 HTTPS 克隆，就会用ssh://协议，比如ssh://git@host:29418/project.git。端口变了，克隆地址就别写错，这一条也算踩坑高频点。
3.4 权限模型进阶：read-only 团队与 ref 权限
权限不只是“谁能推”，Gitblit 还支持按引用（ref）精确控制推送。这个功能藏在仓库编辑页的“Access Restrictions”区域，界面上能看到 Permissions 表，可以选择允许谁推送匹配的 refspec，比如不允许推refs/heads/master，只允许推到refs/heads/feature/*，或者反过来只允许合并到主干。RFC 风格的管理在 Gitblit 里叫做 ref permissions，它的存储方式是：
[user:admin] * = RWD这里的权限串由R（读）、W（写）、D（删除）三个字符组成。类似refs/heads/release/* = RW这样的表达式可以写在用户或团队配置规则里。在users.conf里，一行规则对应一个仓库或通配符匹配仓库，然后是=加权限串。注意，从 1.9.3 开始，权限模型有细微调整：删除分支的权限D被拆开，需要显式赋予。也就是说，即使你给了RW，用户也不能随便删分支，这是防止误删的一层保护。
理解清楚这些，再去看 Web 界面里的权限勾选框就轻松很多了。管理员在“编辑仓库→访问限制→添加权限条目”里选择“ 团队/用户/匿名”，再勾选查看、克隆、推送等动作，实际上就是在后台改写users.conf或gitblit.properties附带的permissions文件。Gitblit 的 Web 界面能编辑这些，但我更建议先在文本文件里写好，再用 Web 界面做小修改，这样出了问题还能定位是配置语法还是权限模型理解的偏差。
4. 从零搭建 Gitblit 1.9.3 服务端：完整步骤与参数说明
4.1 环境准备与 JDK 版本选择
Gitblit 1.9.3 基于 Java 8 编译运行，直接用 JDK 8 是最稳的，我用过 JDK 11 也能跑通，但如果你追求零意外，就老老实实装 OpenJDK 8。装 Java 的命令里没有什么黑魔法，但要注意，CentOS 7 上默认的java可能是 OpenJDK 1.7，所以要先确认版本。
yum install -y java-1.8.0-openjdk java -version如果java -version显示数字以1.8开头，说明环境对了，可以继续。版本不对就去调整/usr/bin/java的符号链接，或者用update-alternatives切换。切换完再java -version确认一遍。这一步能省掉后边大量“莫名其妙的启动失败”，盲目用默认 Java 是第一个大坑。
4.2 下载、解压与目录结构
到官网下载gitblit-1.9.3.zip，解压到/opt/gitblit-1.9.3。目录结构里必须认识这几个东西：
/opt/gitblit-1.9.3/ ├── gitblit.jar ├── gitblit.properties ├── data/ │ ├── users.conf │ ├── git/ │ └── logs/ ├── ext/ └── docs/gitblit.jar是程序本体，gitblit.properties是主配置，data是运行时数据目录，ext目录用来放一些额外的 jar 包或 Groovy 脚本，比如自定义的 hook 脚本。初次启动前，建议在gitblit.properties里确认groovy.enable = true，这样之后如果想加一些自动化逻辑，比如提交邮件通知，就能用 Groovy 脚本直接实现。
4.3 初始化管理员账号与关闭匿名访问
Gitblit 第一次启动后，日志里会打印出一个管理员初始密码。日志位置在data/logs下，文件是gitblit.log。打开日志找到类似下面的行，就是你进入 Web 管理后台的临时凭证。
grep "admin" /opt/gitblit-1.9.3/data/logs/gitblit.log常见输出的形式是admin password is: xxx，拿到密码后马上登录https://host:8443，在用户页面把密码改成自己的，顺手再把邮箱补上。接下来是安全关键一步：改掉gitblit.properties里的git.defaultAccessLevel = VIEW为NONE，并确保git.allowAnonymous = false。这样匿名用户就完全进不来了，仓库列表也不会泄露给没登录的人。
4.4 创建用户与团队
在 Web 界面左侧菜单栏找到“用户”，点“新建用户”。填上用户名、密码、邮箱，邮箱用于接收 Gitblit 发送的通知（如果配置了 SMTP）。角色那里可以勾选can create repos、can create user、can fork等。团队创建更简单，建好团队之后把用户加进去，再对这个团队授权仓库。
如果你偏好用文本文件管理，data/users.conf里每个用户长这样：
[user:zhangsan] password = 6e0da8c9 display = 张三 email = zhangsan@example.com role = [ "#notfederated" ] 可以 = RWDpassword默认是密文，但初版文件里有明文示例，正式环境里建议改成密文，用bcrypt或 SHA-256，Gitblit 支持pbkdf2。整体逻辑很简单，团队维护比用户维护优先，尽量把权限授权给团队而不是个人，否则几十个仓库一个个给用户勾权限能崩溃。
4.5 创建仓库并完成首次推送
仓库创建路径：Web 界面里的“版本库”→新建版本库。填写仓库名，比如team-doc，选择 Gitblit 作为Git仓库类型，默认选“普通仓库”即可。创建完成后得到一个 HTTP 克隆地址和 SSH 克隆地址，形如：
git clone https://git.example.com/gitblit/team-doc.git cd team-doc echo "# hello" > README.md git add README.md git commit -m "init" git push origin master这里有个细节：仓库地址里的/gitblit/是 Gitblit 的 Web 上下文，取决于web.contextPath，默认就是/gitblit。如果你用 Nginx 代理的时候想省略这个路径，就得改web.contextPath=/或做 URL 重写，但改了之后原来的克隆地址就失效了。我的建议是保持默认，让地址统一，省得团队成员手里的 remote 地址五花八门。
首次推送如果提示没有权限，先去仓库的“访问限制”里给用户或团队加上“克隆”和“推送”权限，再试一次。HTTP 方式推送时，Git 会弹出窗口让你输入用户名和密码，输对了才能成功。
4.6 配置 SSH 公钥
用 SSH 协议之前，要让用户把自己本地的~/.ssh/id_rsa.pub内容粘贴到 Web 界面的“用户→公钥”里。粘贴后测试：
ssh -p 29418 git@git.example.com如果返回Welcome to Gitblit的提示，就说明 SSH 服务认你这个公钥了。加公钥这个动作是必需的，不然 SSH 登录会直接失败，而且 Gitblit 的 SSH 端口默认是 29418，很多新手在-p 22上试半天连不上，这不是网络问题，是端口没对上。Git 客户端配置 remote 地址的时候，SSH 路径形如ssh://git@host:29418/team-doc.git，HTTP 地址形如https://host/gitblit/team-doc.git。
5. 避坑指南：Gitblit 1.9.3 的五个高频踩坑现场
5.1 启动失败：端口被占用或 Java 版本不符
现象：执行java -jar gitblit.jar之后，进程不到几秒就退出，或者日志里报Address already in use。原因很简单：端口被别人占了，或者你的 Java 版本不合适。解决方法是先查端口占用，再确认 Java 版本。
netstat -tlnp | grep 8080 java -version如果端口被占，就调server.httpPort，换一个没被占的；如果是 Java 版本过旧，就换 JDK 8。日志里如果出现ClassNotFoundException: javax.xml.bind.JAXBException，多半是 Java 9 以上，Gitblit 1.9.3 不带兼容模块，需要你换 Java 8 到干净，或者手动加javax.xml.bind的 jar 到ext目录。我一般直接换 JDK，不折腾这种兼容性问题。
5.2 已有仓库无法从新版访问：data/git目录被移动
现象：Gitblit 重启后，之前的仓库全都不见了。原因可能是你上次部署时baseFolder用了默认值，启动时的当前目录不同导致数据路径不同，或者 WAR 部署时忘了gitblit.home，导致仓库依旧留在旧目录。解决方法是把你之前备份的data/git目录拷回现在配置的git.repositoriesFolder下，或者干脆把gitblit.properties里的git.repositoriesFolder指到旧目录的绝对路径。数据目录一经确定，最好就固定不要频繁挪动。
5.3 匿名用户还能看到仓库列表
现象：明明在 Web 界面关了匿名访问，但没登录还是能看到team-doc仓库的名字。原因是仓库的“访问限制”里还留着匿名权限条目，或者git.defaultAccessLevel依然被设成VIEW。解决方式是进入每个仓库的编辑页，把“匿名”的权限条目删掉，再把git.defaultAccessLevel改成NONE。还有一个隐藏开关：web.enableRpc如果保持true，可能通过 RPC 接口暴露仓库信息，建议显式关掉。
提示：设置完
git.defaultAccessLevel = NONE后，旧仓库页面里已有的匿名条目不会自动消失，需要手动清理。
5.4 Push 失败：HTTP 方式一直 401
现象：HTTP 克隆没问题，但一执行git push就被拒绝，报 401 Unauthorized。原因大概率是你修改了密码，但 Git 凭据缓存里存的是旧密码，或者你用的是 Gitblit 默认管理员账号登录，但该账号没有推送权限。解决方式：先在 Web 界面确认账号有该仓库的Push权限；然后清掉本地凭据缓存再重试。
git config --global credential.helper cache # 重新输入密码如果你用credential.helper是wincred或osxkeychain，就打开系统的凭据管理器删除旧记录。这类问题并不是 Gitblit 的 bug，很多是凭据缓存惹的祸。偶尔，自己的密码里带了@或:，嵌在 URL 里也会造成解析异常，建议把密码里的特殊字符改掉。
5.5 在线显示乱码：中文文件名编码问题
现象：在 Gitblit Web 界面看仓库里的中文文件名或提交信息，出现乱码。原因是仓库内编码不是统一的 UTF-8，Gitblit 默认按 UTF-8 解析。解决方法：在克隆方式上保证core.quotepath=false，并在 Gitblit 的gitblit.properties里设置web.encoding = UTF-8。仓库端如果能重新配置，尽量在客户端把commit编码统一为 UTF-8。
6. 进阶：用 Groovy Hook 做提交通知与访问日志
Gitblit 1.9.3 的隐藏技能是 Groovy hook 脚本。每个仓库都可以配置钩子，类似于 Git 的原生 hooks，但 Groovy 钩子能访问 Gitblit 的 API，实现邮件通知、工单提醒甚至自动部署。这个功能平时不被太多文档提起，但实际用起来很顺手。
配置方法：在仓库的 Web 页面的“Hooks”区域，会有一个文本输入框，你可以写一个脚本片段。常见用法是在gitblit.properties里指定groovy.hookFolder，然后把.groovy文件放在这个目录里。
// /opt/gitblit-1.9.3/data/groovy/sendmail.groovy import com.gitblit.Gitblit import com.gitblit.models.UserModel import com.gitblit.utils.MailUtils def repository = event.repository def receive = event.receive receive.getAddedBlockList().each { commit -> def shortSha = commit.name.take(8) logger.info("new commit ${shortSha} in ${repository.name} by ${commit.authorIdent.name}") }这个脚本的作用是，每收到一次推送，就在日志里记录一下新增的 commit 信息。event.receive是 Gitblit 传给脚本的事件对象，脚本可以读取新增提交、被删除的提交等。如果你要做邮件通知，利用MailUtils发送 HTML 格式的提交记录，也很容易。当然，脚本出错了不会影响 Git 推送本身，只会记录错误到日志里，所以不用担心写坏 hook 导致仓库不可用。脚本做自动化广播通知，是我个人很推荐的一种轻量用法。
如果你有更好的场景，比如基于提交信息触发 Jenkins 构建，也可以在这里写一个简单的 HTTP 请求：
def url = new URL("http://jenkins.example.com/git/notify/${repository.name}") def conn = url.openConnection() conn.setRequestMethod("POST") conn.setRequestProperty("User-Agent", "Gitblit") conn.connect() logger.info("jenkins notify status: " + conn.responseCode)这样提交一推上来，Jenkins 那边就能收到触发信号。与 Jenkins 的 Git 插件不同，这个方式不依赖轮询，实时性高得多，而且不会给 Gitblit 造成多少性能负担。
部署 hook 脚本前，确认groovy.enable = true，然后重启 Gitblit。日志里如果出现Groovy hook failed的警告，说明脚本里有语法或类加载问题，看gitblit.log里的 stack trace 就能定位。Gitblit 在不改动仓库和用户配置的情况下，热加载 hook 脚本的能力也足够强，改完保存脚本，下次推送自动就生效。
关于日常维护，还要提一个习惯：定期备份data目录。备份时只用停掉 Gitblit，然后打包整个data目录，包括users.conf、git仓库目录、gitblit.properties。仓库多的时候，Git 仓库目录尽量和配置目录分开，备份时对data/git单独做增量备份会快很多。用 cron 定时执行一条 tar 命令是最省心的方案，以防万一哪天服务器磁盘坏了，整个服务端还能原样恢复，不用重建仓库权限。Gitblit 这种文件型存储的好处就是没有复杂的数据库状态，tar 一下就是后悔药，这是我用了三四年 Gitblit 之后最想告诉大家的一句话。希望帮到你。
本文还有配套的精品资源，点击获取
