Gitea vs GitPuk：自托管代码仓库选型对比与SSH密钥配置实战

这两年但凡做技术管理、团队基建，或者纯粹想搭建个人代码仓库的人，多少都会被同一个问题反复折磨：代码到底放哪里？GitHub和GitLab当然好用，可数据合规、私有仓库数量限制、服务器成本、CI/CD配额，随便哪一条都能把人劝退。于是自托管成了越来越多人认真考虑的选项。

选来选去，Gitea 和 GitPuk 这两个名字会频繁出现在备选清单里。一个是把“轻量自托管”做到极致的 Go 单文件应用，社区生态成熟、文档丰富；另一个是主打极简操作和代码阅读体验的后来者，资料相对少，但关注度一直在涨。我把这两个代码管理工具放在同一台 Linux 服务器上各跑了一段时间，也翻了大量文档、Issues 和社区讨论，踩过不少坑。这篇就把两者从部署到日常管理、再到团队协作的完整对比拆开讲清楚。

不管你是个人开发者、三五人的小团队，还是需要给公司搭一套内部代码平台的运维，这篇选型指南应该能帮你少走很多弯路。

1. 先搞清楚：你的团队到底需要哪种代码管理工具

1.1 自托管代码仓库的三类典型诉求

很多人在选型阶段就犯了错，一上来就对比功能列表，比完更懵。我建议先把需求归类，市面上绝大多数的自托管诉求逃不出这三类：

第一类是“数据必须在自己手里”。典型场景是公司内部项目、软件外包交付、或者有合规要求的研发团队。代码放在第三方平台总是有隐患，万一平台调整政策、账号被封、甚至服务下线，焦虑感直接拉满。这类用户的核心诉求是“数据自主可控”，对部署、备份、迁移能力要求极高。

第二类是“成本敏感的个人或微型团队”。GitHub 私有仓库不收费了，但 Actions 的免费额度、大文件存储的限制仍然让人头疼。个人开发者做点小项目、写点博客、存点脚本，不想为基础设施花太多钱，但也不想把代码裸放在公网上。这种场景下，一台低配 VPS 就是全部预算，工具必须得省资源、好维护。

第三类是“想要 GitHub 式体验但不想被绑定”。程序员用惯了 GitHub 的 Pull Request、Issue、Actions 生态，换到别的工具总有点别扭。团队需要一套内部平台，但也不想自己造轮子，希望装完就有接近 GitHub 的体验，最好还支持 GitHub Actions 的语法习惯。

把需求定在这三类里，再去选型，思路就清晰多了。Gitea 和 GitPuk 都属于“轻量级自托管 Git 服务”这个大类，但它们对这个大类的理解、取舍，其实差别非常明显。

1.2 为什么把 Gitea 和 GitPuk 放在一起比较

市面上的对比文章大多是 Gitea 对 GitLab，但 GitLab 那个资源占用，光内存动不动就是几 GB，和轻量两个字根本不沾边。真正让选型陷入纠结的，恰恰是 Gitea 和 GitPuk 这种都标榜“轻量”“快速”“部署简单”的工具。

我第一次看到 GitPuk 的时候，直觉是“又一个 Gitea 换皮”？后来仔细看它的设计理念和实现方式，才发现它走的是另一条路。Gitea 选择的是“把功能做全，把重量做轻”，集成了 Issue、PR、Wiki、Actions、项目管理、包仓库，几乎是半个 GitLab。GitPuk 的做法更激进，它刻意做减法，把代码托管的核心链路做到极致，砍掉大量外围功能，换来的是更快的页面响应和更低的维护成本。

所以这两者的对比，本质上不是“谁功能多谁赢”，而是“功能全面”和“专注核心”两种产品哲学的对碰。这个对比背后，是团队对自己需求的真实认知。

2. Gitea：用 Go 单文件把“轻量自托管”做成标准答案

2.1 部署和资源占用：一台 1 核 1G 的服务器就够

Gitea 最打动人的地方，永远是部署体验。整个服务就是一个 Go 编译出来的二进制文件，不依赖 Java 运行时、不依赖 Node.js、不依赖一堆共享库。你把它放到服务器上，配一个数据库，跑起来就是一个完整的代码托管平台。

我自己实测过的最低配置是一台 1 核 1G 内存的轻量云服务器，系统是 Debian 11，装好 Gitea 之后跑了几个小团队的内网仓库，内存占用长期在 300M 左右徘徊，CPU 平时基本是空闲状态。这个资源占用水平，直接决定了你可以在多便宜的服务器上跑它，也决定了它能不能塞进 NAS、树莓派这类家用设备里。

数据库方面，Gitea 支持 SQLite、MySQL、PostgreSQL。个人使用或几个人的小团队，直接用 SQLite 就完事，少一个组件少一份运维负担。但要注意一点，如果团队超过十个人，并发访问明显上来，建议还是上 PostgreSQL 或 MySQL，SQLite 在并发写多的时候会出现锁等待，这个我实测过的，仓库大、操作频繁的时候会有点卡。

安装过程简单到什么程度？下载二进制、写一份 app.ini 配置文件、初始化数据库、用 systemd 托管进程，全程十五分钟能搞定。具体的操作步骤我在第五章会详细写，这里先不展开。

2.2 权限模型与 SSH 密钥管理：中小团队最在意的细节

代码托管工具的功能再多，权限和密钥管理做不好，团队根本不敢用。Gitea 的权限模型非常清晰，分四个层级：系统管理员、组织、团队、仓库。可以做到很细的粒度控制，比如某个团队只能读取某个仓库，另一个团队可以推送，还有人是仓库管理员可以管理合并请求。

SSH 密钥管理是自托管场景里必须重视的一环。Gitea 的每个用户都可以在“设置 → SSH 密钥”里添加自己的公钥，支持同时管理多把密钥，比如一台办公电脑、一台笔记本、一台服务器，各添加一把密钥，随时可以删掉任何一把。这个设计对个人用户和团队来说都足够灵活。

Gitea 的 SSH 认证实现方式也值得一提。它不直接接管系统的 SSH 服务，而是在系统 SSH 基础上做了个中间层。你在 app.ini 里配置好 SSH 端口，Gitea 会把用户的公钥写入到它内置的管理逻辑中，而不是直接写进 root 的 authorized_keys。这样做的好处是安全隔离，用户密钥被 Gitea 管理，即使某个用户被删除，他的密钥也会被立即禁用，不存在遗留风险。

实际用的时候有一个坑，很多新手会把 Gitea 配置成普通用户的 SSH 访问，然后发现 git clone 总是提示权限错误。大概率原因是没有把 git 用户的 shell 设置成 gitea 的受限脚本，导致 SSH 登录进来之后直接掉进了系统 shell 而不是 Gitea 的代码处理逻辑。这个坑我后面会给出具体排查步骤。

2.3 生态：Webhook、Actions、迁移工具

如果说部署是 Gitea 的门面，生态就是它的护城河。

Webhook 是 Gitea 非常实用的能力。它支持 push、pull request、issue、release 等事件的回调，当这些事件发生时，Gitea 会向配置好的 URL 发送 HTTP 请求。我们团队就靠这个功能把代码推送和内部聊天工具打通了，push 之后自动发通知，省掉了人工吼“谁又动代码了”的环节。还接了一个简单的 CI 服务，每次 push 自动触发构建，非常方便。

Gitea Actions 是另一个重点。它兼容 GitHub Actions 的语法，也就是说你在 GitHub 上写的 workflow 文件，拿到 Gitea 里基本可以直接跑。这对从 GitHub 迁回来的团队来说太友好了，不必为新的 CI/CD 平台重新学一套语法，runner 用 gitea/act_runner 就能跑起来。我实测过几个常用的 workflow：

• 自动测试：npm test，跑完出报告。
• 自动构建镜像并推送到私有仓库。
• 定时任务：每天凌晨执行脚本生成数据报表。

这三个场景 Gitea Actions 都能稳定胜任。不过要注意，act_runner 如果跑在同一个服务器上，大项目的构建任务会吃掉不少 CPU 和内存，最好单独一台机器跑 runner。

迁移工具也是 Gitea 生态里非常实用的部分。Gitea 内置了从 GitHub、GitLab、Gogs、SVN 等主流平台的迁移功能，只需要填上源仓库地址和凭据，就能把仓库、Issues、Pull Request、Wiki 一次性拉过来。我帮朋友从 GitLab 迁移过一个大仓库，几千个 Issue 和几百个 MR 全部完整迁移，连标签都带过来了，体验很稳。

3. GitPuk：比 Gitea 更“少”，但把代码阅读体验做到极致

3.1 GitPuk 的定位：专注代码托管的最小闭环

GitPuk 这个名字，国内很多开发者还比较陌生。它是一款同样面向自托管场景的轻量级 Git 服务，但在产品思路上和 Gitea 有明显分歧。

如果说 Gitea 是“什么都要有”，GitPuk 就是“只做必须有的”。它的核心功能边界非常克制：仓库托管、代码浏览、分支管理、SSH 密钥认证、基本的用户和仓库权限、以及搜索。至于 Issue 跟踪、Wiki、项目管理、CI/CD 这些，GitPuk 并不打算内置，它的设计逻辑是把专业的事交给专业的工具，代码仓库专注做代码仓库的事。

这个“克制”带来的直接好处是，代码浏览和交互的响应速度非常快。我在同样的网络环境、同样的仓库大小下测试过，GitPuk 的仓库页面加载速度比 Gitea 明显要快，尤其是打开大文件、快速跳转分支、搜索代码片段这些操作，体验非常跟手。如果你有大量时间花在“读代码”上，这个差异是能够明显感受到的。

3.2 差异化设计里值得借鉴的思路

GitPuk 有几个设计思路，我认为即使你最后不选它，也值得了解一下。

第一个是它把“代码阅读者”这个角色的体验放到了很高的优先级。很多 Git 服务把重心放在开发者和仓库管理员身上，GitPuk 特别照顾了那些主要读代码、评审代码的人。比如文件树浏览更高效，支持在页面内快速预览 Markdown 和图片，代码高亮和行号渲染非常轻快，这些细节对日常 Code Review 来说体验提升很明显。

第二个是它的配置管理走的是“单配置文件 + 环境变量”的路子。所有配置都集中在一个文件里，不搞数据库初始化那一套复杂流程，甚至支持直接用环境变量覆盖配置项。对 Docker Compose 部署非常友好，写一个简单的 docker-compose.yml 就能把服务拉起来。相比 Gitea 要下载二进制、写 app.ini、初始化数据库三步走，GitPuk 的起步成本确实更低。

第三个是它内置了更现代的代码检索能力。传统 Git 服务的代码搜索经常用数据库模糊匹配，代码稍微多点就慢。GitPuk 在搜索上做了特殊优化，实测在几千个文件的仓库里搜索关键词，响应时间基本在毫秒级。这一点对想要快速定位问题代码的团队非常有价值。

3.3 正视 GitPuk 的短板

但我也必须说句公道话，GitPuk 当前的成熟度离 Gitea 还有不小差距。

首先是生态差距。Gitea 有大量第三方插件、主题、文档、社区教程，遇到问题在网上一搜基本都有答案。GitPuk 的社区规模小得多，遇到问题更多时候得靠自己去翻源码或者提 Issue 等回复。

其次是周边工具链的成熟度。Gitea 的迁移工具、Webhook 生态、Actions Runner 都是经过大量生产环境验证的，GitPuk 在这些方面还处于从“能用”到“好用”的过渡期。比如它虽然支持 Webhook，但可配置的事件类型比 Gitea 少；迁移工具支持的平台也没有 Gitea 那么全。

第三个是团队规模比较大时的权限灵活性。Gitea 有组织、团队、仓库三级模型，可以灵活划分权限。GitPuk 目前的权限粒度相对简单，适合扁平化的小团队，如果你的团队有复杂的角色分层、外包人员、不同项目组隔离等需求，它的权限模型可能会成为瓶颈。

4. 六项关键能力横评：选型不只看功能列表

这一部分我把两台工具放在同一个维度下横向对比。对比的方式不是“谁功能多”，而是看选型时真正决定使用寿命的那些能力。

4.1 安装部署与运维成本

Gitea 的安装流程我前面已经夸过了，但这里要补充一个运维视角的看法。Gitea 的部署虽然简单，但它的配置项非常多，app.ini 里几百个配置项，新手第一次配置容易出现“不知道哪些要配、哪些可以不配”的困惑。不过好在官方文档对每个配置项都有解释，社区也有大量最佳实践，按着文档走基本不会出错。

GitPuk 的运维成本理论上更低，配置项少很多，容错率更高。但也因为简单，当你需要做一些非标准配置时，反而没有 Gitea 那么灵活。比如 Gitea 可以直接在配置里指定多个 SSH 端口、HTTP 和 SSH 并行、不同仓库走不同存储路径，GitPuk 对这些高级场景的支持就有限。

我的实际感受是：如果团队里有人懂 Linux 系统管理，两个工具都能轻松驾驭；如果完全是“部署完就不管”的情况，GitPuk 的初始配置负担更小，但遇到问题时的处理资源也更少。

4.2 权限体系的灵活性差异

权限体系是团队协作工具的核心，也是最容易忽视的选型维度。

Gitea 的权限模型非常成熟。系统管理员可以做全局控制，组织下面可以建团队，团队绑定一组仓库和一组权限。比如“后端开发”团队对后端仓库有读写权限，但对前端仓库只能读；“实习生”团队对所有仓库只有读权限，不能推送。这种模型能够很好地适应真实团队里复杂的角色关系。

GitPuk 的权限模型更简单直接。它对“仓库管理员”“开发者”“只读用户”的划分清晰明确，对大多数十人以内的小团队完全够用。但如果你有跨部门协防、外部协作、临时授权这些需求，它的灵活性就有点吃紧了。我个人的判断是，如果要支撑 15 人以上的团队，或者有外包、跨团队协作需求，Gitea 的权限模型会更省心。

4.3 SSH 密钥管理的设计差异

SSH 密钥管理在大多数对比文章里都被一笔带过，但实际使用中这是最高频的运维需求。

Gitea 的 SSH 密钥管理做得非常完善。每个用户独立管理自己的密钥，支持多把密钥，支持设置密钥有效期，支持一键吊销。我还特别喜欢一个细节：Gitea 对每个仓库可以设置 deployment key，这是一种只对单个仓库生效的密钥，适合 CI 服务器只访问一个仓库的场景。

GitPuk 的 SSH 密钥管理也是独立于系统用户的，用户可以添加和管理多把公钥，基础的“添加、删除、失效”操作都支持，界面也很简洁。不同点在于，Gitea 对 deployment key、密钥用途分类、SSH 签名密钥这类精细场景的支持更深，而 GitPuk 目前更偏“一把钥匙开一个用户”的简单模式。

如果团队规模小，GitPuk 的简洁管理完全没问题。如果团队大、机器多、需要为 CI 配置专用密钥，Gitea 的精细能力会减少很多后期运维的痛苦。

4.4 CI/CD 与自动化生态的成熟度

CI/CD 是很多团队选型时最关注的点，这也是两个工具差别最大的地方。

Gitea 有 Gitea Actions，兼容 GitHub Actions 的 workflow 语法，这是它的杀手级能力。我已经用它接管了团队的自动化测试、镜像构建和定时任务，完全绕开了 Jenkins 那种重量级系统。更关键的是它的 Runner 部署也简单，一个 act_runner 二进制跑起来，注册到 Gitea 就能接活。对于以前在 GitHub 上写过 workflow 的人来说，迁移成本几乎为零。

GitPuk 没有内置 CI/CD 系统。它的设计哲学是“代码托管和 CI/CD 分离”，你可以通过 Webhook 把 push 事件推给外部的 Jenkins、Drone、Woodpecker 等其他 CI 系统。这种思路不是不行，反而在某些“已有固定 CI 平台”的团队里更干净，但对从零搭一套的团队来说，你得多部署一个系统，预算和运维成本都会上去。

我的建议是：如果你还没有一套趁手的 CI/CD，选 Gitea 会省事很多；如果你已经有一整套外部 CI 流程，GitPuk 的 Webhook 反而能让你保持架构清晰，不重复造轮子。

4.5 数据迁移与备份恢复

从旧平台迁过来，以及定期备份，是代码管理工具里“平时没人提、出事就完蛋”的两件事。

Gitea 的迁移走的是“全量拉取”模式。你只要提供一个源平台的 URL 和访问凭据，Gitea 就能把仓库的全部历史、分支、标签、Issues、PR、Wiki 一整套拉过来。实测从 GitHub 迁移一个带几千 Issue 的项目，过程非常稳定。这种能力对从 GitHub/GitLab 逃离出来的团队非常重要。

备份方面，Gitea 提供了官方的 dump 命令，一条命令就能把代码仓库、数据库、配置文件、附件全部打成一个压缩包。恢复的时候也简单，解压、导入、启动，三步走。我从实践里总结出一个备份策略：每天凌晨自动 dump，保留最近 30 天的备份，异地再存一份。这样就算服务器被清空，也有能力在半小时内恢复全部代码。

GitPuk 目前支持基础迁移，可以从其他 Git 服务导入仓库，但像 Issue 这种元数据的迁移支持还不完整。备份方面，因为它的数据模型更简单，备份仓库和配置文件的难度反而低一些，直接用文件系统快照就能搞定。但因为社区资料少，具体的恢复流程需要自己摸索，这点不如 Gitea 省心。

4.6 社区活跃度和长期维护风险

自托管工具最怕的不是功能少，而是项目停更。代码管理工具是基础设施级别的软件，一旦停更，积累的 Bug、安全漏洞都会变成长期风险。

Gitea 在这方面非常让人放心。它有独立的发展基金会，有稳定的核心维护团队，版本更新频率大约每月一个稳定版，社区的 PR、Issue 响应都非常活跃。从 2016 年项目启动到现在，一直保持持续迭代，这件事本身就很有说服力。

GitPuk 的社区规模相对小，更新节奏也更慢。这不代表项目一定会停止维护，但你需要评估一个问题：如果你的团队深度依赖某个小众工具，而工具的维护者因为精力、资金等原因放缓更新，你的团队有没有能力应对？如果没有，那选更主流的工具显然是更稳妥的选择。

5. Linux 环境下 Gitea 安装与 SSH 密钥管理实录

这一部分直接上实操。如果你已经被上面的对比说服，决定先试试 Gitea，那下面的步骤能帮你少踩坑。GitPuk 的部署因为资料还不算太多，这里就不展开了，重点讲 Gitea 在 Linux 环境下的完整安装流程和密钥管理细节。

5.1 从二进制安装到 systemd 托管

我的推荐方式是直接跑官方编译好的二进制文件，不推荐用包管理器装的旧版。Gitea 版本更新快，旧版本往往缺失新功能和安全补丁。

创建系统用户并下载二进制：

bash复制# 创建专用系统用户，不分配 shell，提高安全性
sudo adduser --system --group --disabled-password --shell /bin/bash git

# 切换到 /usr/local/bin 目录下载指定版本
cd /usr/local/bin
sudo wget -O gitea https://dl.gitea.com/gitea/1.21.0/gitea-1.21.0-linux-amd64
sudo chmod +x gitea

这里有个细节，一定要把 git 用户的 shell 设置为 /bin/bash 而不是默认的 /usr/bin/git-shell，否则后续 SSH 访问会出问题。Gitea 官方的安装脚本会自动处理一些目录结构，但手动安装更能理解每一步在干什么。

创建数据目录：

bash复制sudo mkdir -p /var/lib/gitea/{custom,data,log}
sudo chown -R git:git /var/lib/gitea/
sudo chmod -R 750 /var/lib/gitea/

配置文件统一放在 /etc/gitea/ 下：

bash复制sudo mkdir -p /etc/gitea
sudo chown root:git /etc/gitea
sudo chmod 770 /etc/gitea

这里把 /etc/gitea 的属主设置成 root:git，权限 770，是因为 Gitea 的 Web 安装程序需要短暂写入权限，装完再收紧。很多教程没提这一步，导致安装过程中提示无法写入配置。

使用 systemd 托管进程。Gitea 官方仓库里有现成的 service 文件，贴出来直接保存到 /etc/systemd/system/gitea.service：

ini复制[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target

[Service]
RestartSec=2s
Type=simple
User=git
Group=git
WorkingDirectory=/var/lib/gitea/
ExecStart=/usr/local/bin/gitee web --config /etc/gitea/app.ini
Restart=always
Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea

[Install]
WantedBy=multi-user.target

启动并设置开机自启：

bash复制sudo systemctl daemon-reload
sudo systemctl start gitea
sudo systemctl status gitea
sudo systemctl enable gitea

然后浏览器访问 http://服务器IP:3000，进入 Web 安装向导。填写数据库、站点名称、基础路径等信息。个人使用或小团队直接选 SQLite，省事。

5.2 配置 SSH 密钥的几个关键点

很多人在 Gitea 上配好 SSH 密钥后，clone 仍提示 Permission denied，十有八九是下面几个原因。

第一，确认 SSH 端口。Gitea 默认会尝试使用 22 端口，但如果你的服务器上 22 端口已经被系统 SSH 占用了，需要在 app.ini 里给 Gitea 分配一个别的端口，比如 2222。然后客户端 clone 时用 ssh://git@服务器IP:2222/用户名/仓库名.git。

第二，确认 git 用户的 SSH 配置。Gitea 官方推荐在 /home/git/.ssh/authorized_keys 里用特殊格式的密钥行来区分不同用户。你在 Gitea Web 界面添加公钥后，系统会自动追加一条验证脚本到 authorized_keys。如果这条脚本被破坏，比如被其他工具覆盖了，SSH 认证就会失效。

第三，确认 Home 目录权限。git 用户的 .ssh 目录必须是 700 权限，authorized_keys 必须是 600 权限。如果权限太宽松，SSH 服务会拒绝读取这个文件：

bash复制sudo chmod 700 /home/git/.ssh
sudo chmod 600 /home/git/.ssh/authorized_keys

第四，如果改了 Gitea 的 SSH 端口，要确认防火墙放行。用 ufw 的话执行：

bash复制sudo ufw allow 2222/tcp

我排查过很多次 SSH 问题，八成以上都是以上四个原因里的一个。按照顺序排查，很快能定位。

5.3 多用户与团队密钥管理技巧

团队场景下，SSH 密钥管理有几个实用技巧，是文档里不会特意写但实际很有用的。

第一，建议每人至少维护两把密钥，一把办公室电脑用，一把笔记本用。用户在 Gitea 的设置页面可以分别添加，并给每把密钥命名，比如“work-pc”“laptop-2024”。这样某台设备丢失或报废，只需要吊销对应的那一把，不影响其他设备。

第二，CI 服务器不要用某个人的个人密钥。应该创建专门的部署用户，比如 ci-bot，给它单独分配密钥，并且只给它需要的仓库的访问权限。这样即使 CI 服务器被攻破，攻击者拿到的也只是一个受限部署账号，而不是某个开发者的完整权限。

第三，定期审查密钥。我建议每季度检查一次 Gitea 用户列表，确认有没有离职人员或过期账号还挂着有效密钥。Gitea 管理员可以在后台直接禁用账号，停用后他的全部密钥即时失效，这比逐个删除密钥快得多。

5.4 常见 SSH 问题排查链路

如果你开了 SSH 但还是连不上，我习惯用下面这条链路排查，分享出来供参考：

1. 先确认端口通不通：telnet 服务器IP 2222，不通就查防火墙和安全组。
2. 再确认服务在跑：systemctl status gitea，确认 Gitea 进程正常监听。
3. 然后尝试带调试信息连接：ssh -v -p 2222 git@服务器IP，看输出卡在哪一步。
4. 如果能看到 authenticated 字样，说明 SSH 认证已经过了，问题大概率出在 git 用户的 shell 或 Gitea 的 SSH 处理配置上。
5. 最后去 Gitea 日志里找答案：tail -f /var/lib/gitea/log/*.log，Gitea 会把 SSH 处理失败的原因写进日志里，比盲目猜配置高效得多。

6. 我的选型建议：按场景做减法，不要按功能做加法

对比了这么多，最后聊点实在的。选型这件事，最忌讳的就是“功能越多越好”。功能越多，占据的资源越多，维护负担越重，学习成本越高，真正用得上的可能只有三五个功能。我建议按场景做减法，而不是按功能做加法。

6.1 适合选 Gitea 的三种团队

第一种是从 GitHub/GitLab 迁回自托管的团队。因为 Gitea 的迁移工具完整、Actions 语法兼容 GitHub，团队的心理接受度更高。实测下来，从 GitHub 迁过来几乎是无感的，文档和操作习惯都能延续。

第二种是 15 人以上、或者有跨团队协防需求的组织。Gitea 的四级权限模型能很好地支撑复杂角色关系，组织、团队、仓库三个层级可以灵活组合，外包人员、只读访客、管理员都有清晰的权限边界。

第三种是需要一套“开箱即用全套能力”的团队。Issue 跟踪、Wiki 文档、项目面板、包仓库、CI/CD，Gitea 默认就带着一套完整能力，省去自己集成部署多个系统的成本。哪怕有些功能前期用不上，也给了团队未来扩展的余地。

6.2 更适合选 GitPuk 的场景

GitPuk 也有它真正发光的位置。如果你的团队是五人以内的极简团队，没有复杂的权限诉求，不需要内置 Issue 和 CI/CD，只想要一个代码托管的地方，同时特别在意代码浏览和搜索的响应速度，那 GitPuk 的轻量简洁反而是优势。它启动快、配置少、界面干净，部署完几乎不用管，很适合“代码放在自己手里”这个最小需求。

另外一个值得考虑 GitPuk 的场景是你已经有成体系的周边工具链。比如团队已经在用飞书文档、独立的问题跟踪系统、外部的 CI 平台，那 GitPuk 只负责“管代码”这个本职，反而能避免和既有系统功能重叠带来的混乱。

6.3 选完工具后，真正决定体验的三件事

工具选定了只是开始。根据我的实际经验，真正决定自托管代码平台体验的，往往是这三件事：

第一件事是备份策略。代码数据是无价的，你必须把备份当成和搭建系统一样重要的事来做。我给团队定的规矩是：代码仓库每天全量备份，备份文件保留 30 天，并且至少存到两个不同的物理位置。这个习惯曾救过我一次，服务器硬盘突然故障，我们花了不到半小时就把全部代码恢复到新机器上，团队几乎无感知。

第二件事是权限管理流程。工具提供了完善的权限模型，如果不把“用户开通、权限变更、离职回收”的流程跑起来，权限模型再强大也没用。我建议指定一个人专门负责仓库权限的审批，新员工入职开通对应的仓库权限，离职时立即禁用账号。定期检查账号列表，确保没有僵尸账号。

第三件事是接入团队自己的工作流。工具只是载体，关键是让代码托管、代码评审、CI 构建、发布部署这条链路跑顺。Gitea 的 Webhook 和 Actions 能帮你把这条链路自动化，把精力从繁琐的流程中解放出来。只要这条链路是顺的，用哪个工具反而没那么重要了。

我个人的体会是，自托管这件事一旦走上正轨，带来的自由和安心是第三方平台给不了的。它意味着你的代码、你的构建记录、你的协作历史，全部由你自己掌控。从这个角度看，花一个下午时间把选型和部署做对，是一件性价比极高的事。希望这篇对比能让你在做决定时更笃定一些。