项目:gogs/gogs | 星数:47906 | 语言:Go | 协议:MIT | GitHub仓库
更新日期:2026-10-29 · 作者:CodeArts 编辑部
自建代码托管服务,很多人第一反应是 GitLab——但它至少 4GB 内存起步,对一个三五人的小团队或一台 1 核 1G 的 VPS 来说过于沉重。Gogs 的定位正好相反:Go 单二进制、内存占用常在几十 MB、一条命令就能跑。47906 星、MIT 协议,是最经典的轻量方案。
它的边界也很清楚:Gogs 志向是"极简",功能克制;要更完整的生态(Actions、包管理、组织权限细化)时,同样出自 Gogs 的 Gitea 或 Forgejo 更合适。
| 项目 | 特点 | 适用 |
|---|---|---|
| Gogs | 极轻、单二进制、功能精简 | 低配机器、个人、小团队 |
| Gitea | Gogs 分支,活跃、功能完整、内置 CI | 中型团队 |
| Forgejo | Gitea 的社区治理分支 | 重视社区治理 |
如果今天从零开始,且在意持续维护与 CI 能力,Gitea 通常是更务实的选择;如果有低配服务器、只需要一个稳的代码仓库,Gogs 依然是省心之选。
docker run -d --name=gogs \ -p 10022:22 -p 10880:3000 \ -v /var/gogs:/data \ gogs/gogs
然后浏览器打开 http://服务器IP:10880 进入安装向导。几个必填项要提前想好:
| 配置 | 建议 |
|---|---|
| 数据库类型 | 小团队用内置 SQLite 即可;多用户用 MySQL/Postgres |
| 应用 URL | 填最终域名和端口,装完再改需要动配置文件 |
| SSH 端口 | 容器映射的端口,如上面的 10022 |
| 域名 | 填域名,影响仓库克隆地址生成 |
SQLite 的坑在于并发写入较弱,团队超过十人且仓库频繁推送时建议换 Postgres。用 SQLite 时记得备份 /data/gogs/gogs.db。
暴露到公网必须上 HTTPS,否则 SSH 之外的凭据传输都是明文。Nginx 配置:
server {
listen 443 ssl;
server_name git.example.com;
ssl_certificate /etc/letsencrypt/live/git.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/git.example.com/privkey.pem;
client_max_body_size 512m;
location / {
proxy_pass http://127.0.0.1:10880;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
client_max_body_size 不调会让大仓库推送报 413。X-Forwarded-Proto 不加会导致页面里的链接退回 http,混合内容被浏览器拦下。
容器内的 SSH 服务同样要映射出去,且应用配置里的 SSH 端口必须与实际映射一致,否则推送会提示无法连接——这是新装最常见的错误。
# 生成密钥 ssh-keygen -t ed25519 -C "you@example.com" # 加进 Gogs 用户设置后测试 ssh -T git@git.example.com -p 10022 # 克隆 git clone ssh://git@git.example.com:10022/team/project.git
注意 URL 格式:非 22 端口必须用 ssh:// 前缀写法,git@host:path 的简写在自定义端口下会解析失败。
# 整个数据目录(含仓库、SQLite、配置、头像) tar -czf gogs-backup-$(date +%F).tar.gz /var/gogs # 用外部数据库时单独导出 mysqldump -u gogs -p gogs > gogs-db-$(date +%F).sql
恢复就是把目录解包回原位、重启容器。真正容易出问题的是版本升级:跨大版本升级前务必备份,并先在一台测试机上演练。Gogs 的二进制升级相对简单,容器版换 tag 重启即可。
如果哪天需要更完整的功能,Gitea 官方支持从 Gogs 迁移:指向同一个数据库与仓库目录启动 Gitea,它会自动执行升级脚本。逆向(Gitea → Gogs)不可行,所以这个决定是单向的。建议在首次安装时就判断清楚——如果你预计半年内会需要 Actions、组织权限细化、包管理,一开始就用 Gitea 能省掉一次迁移。
一句话总结:Gogs 不是功能最全的,但它是最不容易把一台小服务器压垮的。知道它的边界,用起来会很稳。
需要极低资源占用、只需基础仓库与 Issues 功能,选 Gogs;需要内置 CI(Actions)、更细的组织权限、包管理等完整能力,选 Gitea。两者可单向从 Gogs 迁移到 Gitea,反向不可行,所以宁可在开始时选得完整一些。
常见原因是容器 SSH 端口映射与 Gogs 配置里的 SSH 端口不一致,或克隆 URL 格式不对。自定义端口必须写成 ssh://git@域名:端口/组/仓库.git,不能用 git@host:path 简写。
十人以内、推送不频繁时足够,且备份只需拷贝单个文件。团队变大或并发写入明显增多后,SQLite 的写锁会成为瓶颈,建议改用 Postgres 或 MySQL。