代码托管平台

GitHub 作为目前最流行的代码管理平台，基本上是目前个人开发者和小型团队管理代码的唯一平台。本文是系列文章的上篇，旨在介绍使用 forgejo 作为 GitHub 的替代品来实现简单的代码管理功能。下一篇计划介绍使用 Crow CI 来作为 CI/CD 的工具替代 GitHub Actions，至于 GitHub Codespaces 或者 Copilot 则不再额外介绍。前者有 devcontainer 或者其他本地开发环境的配置，后者有 Claude Code 或者 Codex 等其他 AI 辅助工具替代。

 

部署选型

在配置完 轻量 Git 仓库后，我开始寻找一个能够替代 GitHub 完成更多开发流程和代码管理的平台。比起和 GitHub 的完全兼容，我更看重的长期开源治理，轻量化部署维护和自主托管主权。本来我也想尝试 Gitea，但是看了曾经 Gitea 被商业机构控制时开发者和社区成员的公开信之后，我选择了 Forgejo。

Forgejo 在普通的代码管理方面和 Gitea 或者 GitHub 等都没有太大的区别。对于我现在涉及的普通开发项目，issue, pull request, wiki 等各方面都没有太多的区别。一个主要区别就在于 GitHub Actions 上，这也是下一篇 CI/CD 工具关注的重点，在此不多做介绍。

一开始我是把 forgejo 部署在 zeabur 上的。当时这个服务商提供每月 $5 的免费额度，可以用来托管 docker 镜像。因此整个项目就是一个容器里的服务：所有的仓库和大文件数据都放在镜像里，数据库也用的是简单的 SQLite3。直到5月份该公司简单直接地停止了免费服务，我赶在服务器关闭前紧急打包了整个数据文件夹里，开始迁移到自己的云服务器上。由于自己的服务器上已经运行了一个 PostgreSQL 容器，这次迁移还要把 SQLite3 里的数据迁移到 PostgreSQL出来。

新的部署任务很简单，分为下列几步：

  1. 在本地验证迁移下来的数据
  2. 在本地的容器里使用 forgejo --database postgres --type zstd --file postgres_db.tar.zst 把数据库文件保存为 Postgres 的格式。同时把剩下的数据文件上传。
  3. 在远端里解压迁移的数据，创建新的数据库用户和数据库，把数据文件导入到容器。
# 创建供 forgejo 通信的 docker 网络
docker network create forgejo

# 登录到容器里
sudo docker compose exec psql_db psql -U postgres

# 在 PG 容器里执行操作
CREATE ROLE forgejo WITH LOGIN PASSWORD '[redacted]';
CREATE DATABASE forgejo OWNER forgejo;
q

# 测试创建用户的结果
sudo docker compose exec psql_db psql -U forgejo -d forgejo

# 把 sql 文件导入到容器里
cat forgejo-db.sql | sudo docker run --rm -i \
  --network forgejo \
  -e PGPASSWORD="[redacted]" \
  postgres:latest \
  psql -h psql_db -U forgejo -d forgejo
  1. 验证数据库导入正常后，把剩下的数据文件传到文件夹，同时在 app.ini 文件里修改数据库的连接配置。
[database]
DB_TYPE = postgres
HOST = psql_db:5432
NAME = forgejo
USER = forgejo
PASSWD = [redacted]
SSL_MODE = disable
  1. 最后配置 compose 文件，一把启动容器。
networks:
  forgejo:
    external: true

services:
  forgejo:
    image: codeberg.org/forgejo/forgejo:15
    container_name: forgejo
    environment:
      USER_UID: 1000
      USER_GID: 1000
      TZ: America/New_York
    restart: always
    networks:
      - forgejo # 用于连接外部 PG 服务器的网络
    volumes:
      - ./data:/data # 数据文件
    ports:
      - '3000:3000'
      # - '2222:22' Git 的 SSH 协议端口，这个实例中禁用

迁移后一切正常，所有旧的配置正常生效， Git 仓库和用户数据也都完整保留。forgejo 容器在运行时大约消耗 150 MB 的内存，而 PostgreSQL 则消耗大约 100 MB 的内存。对于现在这台服务器算是绰绰有余了，我也不用担心再次被类似 zeabur 这样的服务商删库了。

配置和迁移感受

这个系列的工具都强调自主控制，自由组合和轻量化部署。对于在意数据和自由软件生态并且愿意做简单维护的个人或者小团队来说，是一个非常不错的选择。之前我开发的基于 SSH 的轻量 Git 仓库虽然也提供了一个思路，但是在实际部署中我发现 SSH 协议的 Git 服务器反而没有那么容易配置，尤其是很多云平台在处理持久化的 SSH 私钥和仓库数据方面比较麻烦。SSH 的轻量仓库看起来更像是可以做成 Google Run 那样的工作容器，在收到 Git 请求把内容写入挂载的存储。这样比较下来， Forgejo 还是提供了更完善的代码管理流程和更加直观的代码管理方式。

技术特点

Forgejo 一个比较好的的特点是可以组合不同的配置。数据库可以选择 SQLite3, PostgreSQL 或者 MariaDB (MySQL)。大文件可以选择 S3/MinIO 等远端存储或者本地存储。甚至 Git Over SSH 也可以选择内建的 SSH 服务器或者系统自带的服务器。这也减少了对某个单一组件或者服务的依赖。

下一步部署

目前来看大部分配置都是可以继续配置的，项目官方也提供了详细的配置文档。但是就目前作为个人的代码平台来说，我只打算分成 Forgejo 服务器， PostgreSQL 数据库和 Crow CI 流水线三部分就行了。Crow CI 将会在下一篇介绍。而对于 Forgejo 这一块的配置，我的计划是渐进地添加一些功能，包括邮件管理和对 Forgejo Release/Packages 的配置，目前的想法依然是利用 Cloudflare 低价的邮箱功能（或许也要配合一个其他的发件服务）和 R2 的对象存储。

下一部分，我将着重介绍 Crow CI 这个 CI/CD 工具。这一块的配置就是为了对标 GitHub Actions，同时我也会简单提及他竞品，分享我对这个领域曾有过的误解以及分享我在配置过程中遇到的问题。

评论系统尚未配置。请在 .env 中填写 giscus 所需的环境变量。