2026 年 7 月 16 日，Forgejo v16.0 正式发布。这个由社区驱动的自托管代码协作平台，从 2022 年被迫从 Gitea 分叉至今，已经走到了第四个年头。v16.0 不是 LTS 版本——它的支持周期只到 2026 年 10 月 29 日——但在这个三个月的开发周期中，Forgejo 团队塞进了足够多的实质性改进，让这次发布值得认真审视。
在 Lobsters 上，v16.0 的发布公告拿到了 69 分和 7 条评论。不算爆炸，但足够说明一件事：关注 Forgejo 的人正在变多，而且他们关注的不只是「又一个 Git 托管工具」——他们关注的是这个项目独特的轨迹。
从「社区自救」到硬分叉：一段必须回顾的历史
要理解 v16.0 的意义，需要先理解 Forgejo 的来路。
2022 年 10 月，Gitea 项目的域名和商标在社区不知情的情况下被转移给了一家商业公司（Gitea Ltd.）。社区写了一封公开信要求澄清，最终确认了这一事实。Forgejo 在同一时间成立，最初以「软分叉」的形式出现——类似 LineageOS 之于 Android，在 Gitea 的基础上构建，同时保持与上游的紧密同步。
2024 年初是一个转折点。Forgejo 宣布成为硬分叉，不再自动合并 Gitea 的提交，代码库开始独立演进。Forgejo 也不在 GitHub 上开发——它使用自己的 Forgejo 实例进行开发和测试，用 Forgejo Actions 替代 GitHub Actions，用 Weblate 替代 Crowdin 做本地化。这是一种罕见的彻底的「eat your own dog food」——不是口号，是工程现实。
Forgejo 由 Codeberg e.V. 托管，这是一个注册在德国柏林的非营利组织。根据 Forgejo 官方对比页面，它与 Gitea 之间存在几个结构性差异：
- 许可证纯净度：Forgejo 的所有代码和文档都以自由软件许可证发布。Gitea 采用了 Open Core 模式，并要求贡献者签署版权转让协议——即使是 MIT 许可的代码。
- 安全披露：Forgejo 的安全公告向所有人开放。Gitea 的安全预警仅对客户开放。
- 测试覆盖：Forgejo 有端到端测试和升级测试。Gitea 截止 2025 年 6 月只有示例性的浏览器测试。
- 锻造联邦（forge federation）：Forgejo 正在推进联邦化，有月度进度报告。Gitea 在这个方向上没有公开进展。
这些差异在 2022 年可能只是措辞上的分歧，但到 2026 年，它们已经固化成了两种不同的产品哲学。
v16.0 的新功能：不只是「加了好多功能」
如果你只看更新列表的长度，v16.0 似乎是一个典型的「大版本」——加了一堆功能，修了一堆 bug，升级时注意 breaking changes。但仔细看每一项改动背后的动机，会发现一个规律：Forgejo 正在系统地消除那些让开发者觉得「自托管不如 GitHub」的微小摩擦。
通知粒度：不再被 repo 轰炸
v16.0 引入了细粒度的仓库监控设置。用户可以分别选择对 Issues、Pull Requests 和 Releases 是否接收通知。以前只能全局开关一个仓库的通知，现在可以选择只关注自己关心的部分。
这听起来像是 GitHub 早就有的功能。但 GitHub 的通知系统是多年迭代的结果，背后有庞大的产品和设计团队。Forgejo 作为社区项目，用三个月完成这个功能，并且重构了通知后端以支持未来的进一步细化，这个推进速度值得认可。
多行代码评审：差评终于可以跨行了
v16.0 支持在 PR 评审中对多行代码添加单条评论。操作方式是按住 Shift，点击第一行的加号，拖动到最后一行的加号。
这是 GitHub 在 2021 年就已经引入的功能。但自托管平台与 GitHub 的比较不应该止于「你有的功能我有没有」——关键在于是不是做得更好。Forgejo 在这一版中同步解决了一个更深层的问题：评审评论的定位准确度。
v16.0 对评论放置逻辑做了五项修复。核心思路是使用 git blame --reverse 追踪代码行在 commit 历史中的迁移——当一行代码在后续 commit 中被移动，评论仍然能跟随到正确的位置。被删除的代码行上的评论也能正确标记为「过期」。这些改动分散在五个 PR 中（forgejo!12015、!12054、!12107、!12055、!12092），加起来超过 2000 行改动。
Lobsters 用户 nicoco 的评论很朴实：「我不太熟悉代码评审，过去在给一些自由软件提交补丁时，经常搞不清楚评论对应的是哪段代码。这个改进直接解决了我的困惑。」这就是工程上「好的改进」的典型特征——它解决的问题不需要解释，用过的人一看就懂。
PR 提交列表重新设计
v16.0 重新设计了 PR 页面的提交列表布局。更干净，在不同屏幕尺寸上表现更好。目前只用在 PR 页面，但计划逐步推广到其他有提交列表的页面。
这不是什么革新，但值得注意——Forgejo 在打磨 UI 细节上的投入正在增加。对于一个开源自托管项目来说，UI 通常是最被忽视的部分。Forgejo 在这个方向上持续投入，说明它在意日常使用体验，而不满足于仅仅做一个功能可用的替代品。
Actions 改进：自动化可以更精细
Forgejo Actions 获得了两个重要增强。
第一个是手动工作流优先执行。你可以将某个 workflow run 标记为优先，Forgejo Actions 会把它排到队列最前面。对于需要紧急部署的场景，这个功能省去了取消其他正在运行的任务的麻烦。
第二个是授权集成（Authorized Integrations）。这是一个更深层的机制：Forgejo 可以通过 JWT 对外部系统进行认证和授权。它允许从本地 Actions 或以配置好规则的方式，让任意 JWT 被 Forgejo 验证。这个能力在实践中的意义是：你不需要在 Forgejo 里配置和轮换访问令牌了。 外部系统（比如 AWS、GitHub Actions、GitLab CI/CD）可以直接通过配置好的 JWT 规则访问 Forgejo 的 API 和 Git 仓库，不需要在 Forgejo 中存储任何静态密钥。
从工程角度看，这是一个安全性的提升——它把「共享密钥」模型替换成了「签名验证」模型，减少了密钥泄露的攻击面。
其他值得注意的改动
- 仓库迁移进度显示：迁移 Issues 和 PR 时可以看到进度（默认每批 45 条），可以确认长时间运行的任务没有卡死。
- 头像尺寸优化：生成两种缩小版本的头像变体，在不需要全尺寸的地方传输更小的图片，节省带宽。
- 团队添加更方便：在组织成员列表上直接弹窗添加成员，一次可以加入多个团队。
- 入站对象一致性检查：Git 现在会检查入站对象的完整性，拒绝损坏或异常的对象，防止仓库进入不一致状态。
- Git hook 示例文件清理：不再在每个仓库中填充示例 hook 文件，实例级 hooks 集中存储，每个仓库节省约 20 KiB。大型部署上这个数字会累积成可观的磁盘空间。
- 工作流日志 API：新增获取 workflow run 和单个 job 日志的 API 端点。工件（artifacts）也可以列出、下载和删除。
- 组织模型增加创建时间：API 返回的组织信息现在包含
created_at字段。 - 管理员能力增强：实例管理员现在可以管理用户的访问令牌（列出、发放、删除），按 2FA 状态筛选用户列表。
Breaking Changes 中的工程判断
v16.0 有三项值得留意的 breaking changes，每一项背后都反映了项目在安全性和合规性上的取舍。
SSRF 强化
Forgejo 在配置中允许管理员通过 [migrations].ALLOWED_DOMAINS 等设置限制 Git 镜像可以访问的主机。但之前存在边缘情况让这些限制失效——比如 Git 在 HTTP(S) 访问仓库时跟随 HTTP 重定向。v16.0 强制设置了 http.followRedirects=false，同时修复了多个相关漏洞。
实际的副作用是：如果远程 Forgejo 仓库被重命名或转移所有权，镜像会报错而非自动跟随重定向。管理员需要手动更新镜像地址。
EXIF 剥离功能的移除
Forgejo v13.0 增加了上传头像时剥离 EXIF 元数据的功能。但项目随后发现用于实现此功能的库是 AGPL 许可的——Forgejo 本身是 GPL 许可，AGPL 的额外条款（特别是网络使用触发源码分发义务）与项目的许可证策略不兼容。
Forgejo 的选择很直接：移除功能，直到找到替代方案。 这种「宁可砍功能也要保持许可证干净」的态度，与项目成立之初对 Gitea「Open Core」模式的批评一脉相承。
容器中受信代理默认值变更
Forgejo 的容器镜像此前默认将 REVERSE_PROXY_TRUSTED_PROXIES 设为 *，信任所有来源的代理头。在用户同时开启了反向代理认证且 Forgejo 的 3000 端口暴露在不可信网络中的情况下，攻击者可以利用 X-WebAuth-User 头冒充任意用户。
v16.0 将容器镜像中的默认值从 * 改为空。升级后如果你依赖反向代理认证，需要显式配置 [security].REVERSE_PROXY_TRUSTED_PROXIES——比如 127.0.0.0/8,::1/128,172.16.0.0/12。
这不是一个友好的变更，但是一个正确的变更。 默认安全的优先级高于向后兼容的便利性。
自托管 Git 锻造的格局：Forgejo 的位置
2026 年的自托管 Git 市场比 2022 年拥挤得多。把 Forgejo 放在地图上看，它的位置大致是这样的：
GitLab CE 是功能最全的自托管方案，但也最重——需要 4GB+ 内存，更新和维护成本不低。适合有专职 DevOps 的团队。
Gitea 仍然是轻量级方案中部署量最大的。但它现在是一个商业公司控制的项目，有 Open Core 组件，安全性披露和测试覆盖都不如 Forgejo。
SourceHut 走了一个完全不同的方向——基于邮件列表的工作流，没有 JS，极致简洁。适合偏好这种风格的小团队，但不符合大多数从 GitHub/GitLab 迁移过来的用户的习惯。
Forgejo 卡在一个独特的位置上：它既有 Gitea 的轻量（单二进制，低资源消耗），又有社区治理的透明度和纯净的许可证，并且正在以每三个月一个主要版本的节奏持续缩小与 GitHub/GitLab 在 UX 细节上的差距。
Forgejo 的价值主张很明确：提供一个可信的「退出选项」。 当你不愿意把自己的代码和协作流程绑定在一家商业平台上时，Forgejo 是目前工程质量和治理模型结合得最好的选择。GitHub 的网络效应、Actions 生态、Codespaces、Copilot 集成，这些是自托管方案难以复制的——但这不妨碍 Forgejo 在自己的赛道上持续进步。
从「可行的替代品」到「有吸引力的选择」
v16.0 是一个典型的「基础设施建设型」版本——它的改动大多是渐进式的，没有让你惊叹的 headline feature。但把时间轴拉长来看，Forgejo 过去四年的积累正在从量变走向质变。
2022 年的 Forgejo 是「Gitea 加上社区治理」——功能上几乎一致，差异主要在品牌和治理主张上。2026 年的 Forgejo 已经有了一系列属于自己的特性：联邦化推进、Actions 工作流增强、端到端测试体系、许可证纯净度、持续的 UI 打磨。这些差异单独看都不大，但累积起来意味着 Forgejo 正在成为它自己，而不是 Gitea 的一个副本。
Lobsters 用户 Al3xFor 在帖子里写道：「我过去几天在搭建和调整我的个人 forge，逐步从 GitHub 迁出。体验非常愉快，完全可以推荐自托管。」这可能是对 Forgejo 最好的评价——它不会让迁移变成一个痛苦的过程，它正在降低「拥有自己的代码基础设施」的门槛。
当然，还有一个不可回避的事实：v16.0 只支持到 2026 年 10 月。非 LTS 版本意味着每三个月就要跟进升级。对于偏好稳定性的团队来说，更好的选择是等 v17.0 在 10 月 15 日发布（同样是非 LTS），或者使用 v15.0 LTS（支持到 2027 年 7 月）。
Forgejo 的发布策略——LTS 每年一次，中间错开三个非 LTS 版本——是一个务实的平衡：既有稳定的锚点，又能以较高的频率推送新功能。 这个策略本身也在传递一个信号：Forgejo 是一个有持续演进计划的平台，而不是一个发布后就进入维护模式的项目。
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。
参考链接
- Forgejo v16.0 is available —— Forgejo 官方发布公告，包含完整的功能列表和 breaking changes 说明
- Comparison with Gitea —— Forgejo 官网对两个项目差异的官方说明
- Forgejo Releases 页面 —— 发布历史和 LTS 支持周期
- Gitea vs Forgejo: Which to Self-Host? (2026) —— Contabo 博客的第三方对比分析
- Self-Hosted Git Platforms: GitLab vs Gitea vs Forgejo 2026 —— Dasroot 的技术对比
- Lobsters 讨论 —— 69 分，7 条评论，包含用户对 PR 评审改进和自托管体验的反馈
