Elytra
BlogGit

Git 托管与备份：GitHub、自建 Gitea、NAS 与其他方案

远程仓库不只是 push 的目标——它决定协作、CI、权限与灾备边界。从 GitHub 到自建 Gitea、NAS 与 Codeberg 等替代方案，再到多 remote 镜像与 git bundle，一文理清 Git 托管选型与备份策略。

教程
Composer 2.5
gitgithubgiteaself-hostednasbackupdevops

git push 成功之后，很多人会松一口气：代码「已经在云端了」。

但远程仓库承担的不只是存储。它决定 谁能协作、PR 怎么走、CI 跑在哪、Issue 和 Release 挂在哪、大文件 LFS 存哪、账号被封或服务商变更时你有没有退路。托管选型与备份策略，和 Git 核心概念、客户端工具、大文件与 LFS 一样，是日常开发里迟早要碰到的基建问题。

核心结论

  • Git 本身是分布式的——每台 clone 下来的机器都有一份完整历史；「托管」指的是你约定的**权威远程（remote）**与围绕它搭建的协作设施。
  • 没有单一最优解：公开开源项目、个人私有仓库、公司内网合规、游戏大资产团队，答案完全不同。
  • 备份 ≠ 只有一个 remote：至少做到「第二份可恢复的远程或离线包」，并定期验证能 clone / bundle verify。
  • 自建（Gitea / Forgejo / GitLab）换的是控制权，不是免运维——升级、证书、存储、镜像与灾备仍要有人负责。

1先分清：你在选什么

托管方案通常同时包含几层能力，选型时拆开看，避免「GitHub 能 push 就够了」的错觉：

层次典型能力换平台时的迁移成本
Git 协议层git clone / push / fetch，SSH 或 HTTPS低——改 remote url 即可
协作层PR/MR、Review、Issue、Wiki、Discussion中——历史评论、标签、里程碑难全自动迁移
自动化层Actions / CI、Webhook、包注册表高——流水线语法、密钥、Runner 都要重写或重配
大文件层Git LFS、Artifacts、Release 附件中到高——LFS 对象要单独搬
身份与权限组织、Team、SSO、审计日志高——企业场景常是锁定因素

个人项目往往只用到前几层；团队项目一旦深度绑定 CI 与权限，迁移就不是「换个 URL」那么简单。

Loading diagram…

2GitHub：默认选项，但不是唯一答案

对绝大多数开发者，GitHub 仍是生态最完整的 Git 托管：公开仓库无限、私有仓库对个人免费、与 GitHub CLI (gh) 深度集成，Actions、Copilot、Dependabot、Pages、Packages 形成一整条链路。

2.1适合的场景

  • 开源项目要曝光、要 Star、要他人 Fork 与贡献
  • 个人或小团队私有仓库，依赖 Actions 做 CI/CD
  • 需要成熟的 Code Review、Issue 模板、Release 与社区工具
  • 求职者希望作品集可被 HR / 面试官直接浏览

2.2需要知道的限制

项目免费个人账户（Hobby）大致边界说明
私有仓库 Actions2,000 分钟/月（标准 Linux Runner）1超出需付费或自建 Runner
仓库体积建议 < 1 GB，硬顶约 5 GB2超大历史应清历史或拆仓
单文件 push软限制 100 MB，硬拒绝 > 100 MB3大二进制走 LFS，见 大文件专文
Git LFS 免费额度存储 500 MB、带宽 1 GB/月4游戏资产团队很快不够
商业用途免费档面向个人非商用；公司商用需 Team / Enterprise合规与合同另说

账号与 ToS 风险

SaaS 托管意味着：账号状态、地区政策、服务条款变更，都可能让你一夜之间失去 push 权限或仓库可见性。 公开开源项目尚可 Fork 扩散；仅有单一 GitHub 私有 remote、且无离线备份时，风险集中在「账号」而不在「Git 协议」。

2.3实用建议

  • 公开仓库：把 GitHub 当主协作面，同时加一条只读镜像（见下文备份节）。
  • 私有仓库：至少配置 第二 remote（自建 Gitea、Codeberg、NAS 或另一 SaaS）。
  • 深度使用 Actions 前，评估分钟数；静态站部署还可对照站内 部署平台免费版横评——那是「网站托管」，与「Git 仓托管」相关但不等同。

3自建 Gitea：轻量、够用、自己负责 uptime

Gitea 是用 Go 写的轻量 Git 托管，单二进制即可运行，资源占用远低于 GitLab。功能覆盖中小型团队常见需求：仓库、PR、Issue、Wiki、Actions（较新）、LFS、OAuth 登录、组织与权限。

2022 年后社区还出现了 Forgejo——在 Gitea 治理争议后由社区维护的分支，API 与体验高度相似，下文「Gitea」在实践层面常可互换。

3.1为什么选 Gitea 而不是 GitLab

维度Gitea / ForgejoGitLab（自建）
内存占用常常 512 MB～1 GB 即可跑起来生产环境常建议 4 GB+
安装复杂度Docker 一键、SQLite 单机够用Omnibus 较重，组件多
功能广度核心协作 + 基础 CIDevOps 全家桶、内置 Registry、复杂权限
适合个人、小团队、内网镜像中大型企业想一站式 DevOps

个人或三五人团队，Gitea + 反向代理（Caddy / Nginx）+ 自动 HTTPS 往往就够；不必为了「自建」先扛一套完整 GitLab。

3.2典型部署形态

# 示例：Docker Compose 最小思路（版本与卷路径请按官方文档调整）
services:
  gitea:
    image: gitea/gitea:latest
    ports:
      - "3000:3000"
      - "2222:22"
    volumes:
      - ./gitea:/data

要点：

  1. 数据卷：/data 含仓库、数据库、配置——备份时整卷快照，而不只是 git clone。
  2. SSH 端口：若 22 已被占用，可映射 2222，客户端 ~/.ssh/config 里写 Port 2222。
  3. 数据库：小规模用 SQLite 即可；用户与仓库多了再迁 PostgreSQL。
  4. HTTPS：公网暴露务必走 TLS；内网可用私有 CA 或仅 VPN 访问。
  5. 升级：读 Release Note，先备份卷再拉新镜像；Gitea 提供版本间迁移工具。

Gitea 的定位

把自建 Gitea 当成 「你控制的权威 remote」：数据在你磁盘上、推送不经过第三方账号体系；代价是 补丁、证书过期、磁盘满、断电 都要自己处理。

3.3Gitea 的短板

  • 生态与 GitHub 不能比：第三方集成、市场插件、求职者「晒 GitHub」效应弱。
  • Actions 生态较新，复用 GitHub Actions 工作流常要改语法。
  • 单点故障：一台 VPS 挂了，全队不能 push——需要备份与可选的高可用（多节点、对象存储后端），那是下一阶段的事。

4NAS 当 Git 服务器：顺手，但有边界

家里或办公室已有 Synology、QNAP 等 NAS 时，「顺便开个 Git 服务」很诱人：硬盘本来就在、局域网速度快、不额外付云仓租费。

4.1常见实现

方式说明
厂商 Git 套件群晖 Git Server 等：Web 管理、用户与权限、走 DSM 账号体系
Docker 跑 Gitea / Forgejo与 VPS 部署相同，数据落在 NAS 卷上
裸仓库 + SSHgit init --bare，无 Web UI，极客向

4.2优点

  • 数据物理位置可控，不默认出境；适合对数据驻留敏感、但规模不大的团队。
  • 局域网 git push 传大仓库体验好；可配合 Git LFS 把 LFS 也放在内网。
  • 与 NAS 快照、RAID 结合，误删有一定恢复窗口。

4.3缺点与坑

NAS 不是银弹

  1. 公网访问：要么折腾 DDNS + 端口转发 + TLS，要么只在内网/VPN 用；暴露不当比 GitHub 私有仓更危险。
  2. 性能与并发：NAS CPU 弱于云 VPS；多人同时 push、跑 CI 容易成为瓶颈。
  3. 可用性：停电、盘故障、系统升级失败 → 全队停工；RAID 不是备份。
  4. 协作功能弱：厂商套件往往只有基础 Git；要 PR/Issue 仍建议 NAS 上跑 Gitea 容器。
  5. 离线备份：NAS 本身仍要同步到异地或冷存储，否则火灾/盗窃/勒索软件一次清零。

实用组合：NAS 跑 Gitea 作内网主 remote，定时 git push --mirror 到 GitHub/Codeberg 作异地副本；或反过来，GitHub 开发、NAS 做夜间镜像——取决于谁才是「权威」。

5其他方案速览

5.1SaaS 替代

平台特点适合
GitLab.com免费档私有仓、内置 CI 分钟有限5想要 GitHub 以外第二 SaaS、偏好 MR 流程
Codeberg基于 Forgejo，非营利、欧盟运营开源项目、重视托管方治理与隐私政策
Bitbucket与 Jira 集成深；免费私有仓策略已多次收紧已深度使用 Atlassian 栈的团队
Azure DevOps Repos与 Azure Pipelines、Boards 一体微软云生态、企业采购
SourceHut极简、邮件驱动工作流、无 JavaScript 倾向极简主义者、CLI 派

AWS CodeCommit 已于 2024 年停止对新客户开放，现有用户也需迁移6——新项目不应再选。

5.2自建重量级

  • GitLab CE/EE：功能最全，硬件与运维成本高，适合「公司就是要一套 DevOps 平台」。
  • Bitbucket Server / Data Center：Atlassian 自建路径，与 Jira 绑定深。
  • 纯 git daemon / gitolite / ssh + bare repo：只要协议、不要 UI 时的极简方案；权限靠配置文件，学习曲线陡峭。

5.3与「代码托管」相邻的选择

  • 只托管制品、不托管 Git：例如对象存储 + git bundle 归档发布版——适合发行物备份，不适合日常协作。
  • Monorepo + 单一远程：Google/Facebook 内网自建为主；个人开发者很少需要为此专门搭 Perforce（大文件场景见 专文）。

6备份：Git 分布式，但远程仍可能全丢

「我 push 到 GitHub 了」不是完整备份策略。需要防范的场景包括：

  • 账号被封、误删组织、仓库被 force push 清空历史
  • SaaS 区域性故障（少见但发生过）
  • 自建服务器磁盘损坏、勒索软件加密 NAS
  • 只有 LFS 指针、LFS 对象从未备份

6.1原则：3-2-1 的 Git 版

  1. 至少两份完整历史：本机 + 一个 remote 不算够；两个 independent remote 或 remote + 离线 bundle 更稳。
  2. 两种介质：例如云 SaaS + NAS 快照，或 VPS + 冷硬盘。
  3. 一份离线/异地：与主站点物理隔离。

6.2手段一：多 remote 镜像

# 添加备份 remote（bare 镜像仓）
git remote add backup git@nas.local:backup/myproject.git

# 推送所有分支与标签（镜像）
git push --mirror backup

定时任务（cron / Task Scheduler）里对所有重要仓库执行 git push --mirror，或使用 Gitea 内置镜像 从 GitHub 拉取保持同步。

镜像推送

--mirror 会让 backup 与源 remote 完全一致，包括删除分支。若 backup 上要保留「只增不删」的历史，用普通 git push --all + git push --tags，或从 backup 侧 git clone --mirror 定时拉取（拉取方向相反，backup 只读更安全）。

6.3手段二：git bundle 离线包

git bundle 把整个仓库（含历史）打成单文件，适合 U 盘、对象存储、年度归档：

git bundle create myproject-$(date +%Y%m%d).bundle --all
git bundle verify myproject-20260923.bundle
# 恢复：git clone myproject-20260923.bundle myproject-restored

建议 每季度或每次大版本 对核心仓库打 bundle，并抽检 bundle verify + 试 clone。

6.4手段三：裸仓库克隆 + 存储快照

在备份机上：

git clone --mirror git@github.com:you/repo.git
# 定期：cd repo.git && git remote update

配合文件系统快照（ZFS、btrfs、NAS 快照）可回滚到「误删 remote 之前」的状态。

6.5手段四：别漏 LFS 与元数据

内容备份方式
Git 对象clone --mirror / bundle / 双 remote
LFS 对象git lfs fetch --all 后复制 .git/lfs，或 LFS 服务端卷备份
Issue / PR / Wiki平台导出、API 备份，或接受「只备份 Git 历史」
CI 配置已在仓库里的 .github/workflows 会随 Git 走；密钥在平台侧单独导出

6.6恢复演练

备份从未恢复过，等于没备份。每年至少一次：

  1. 从 backup remote 或 bundle 全新目录 clone；
  2. 跑一遍测试 / 构建；
  3. 若有 LFS，确认大文件能 git lfs pull 且校验通过。

7怎么选：一张决策表

你的情况更稳妥的组合
个人开源 side projectGitHub 主仓 + Codeberg 或 Gitea 镜像
个人私有、偶尔 pushGitHub 私有 或 自建 Gitea 二选一 + 季度 bundle
小团队、无合规硬要求GitHub Team 或 单台 VPS Gitea + nightly mirror
数据不能出内网NAS/VPN 内 Gitea + 内网备份机 clone --mirror
游戏/影视大二进制托管方 LFS 配额 + LFS/Perforce 策略；备份必须含 LFS 存储卷
公司已买 Azure/GitLab跟采购栈走，个人 fork 镜像到 GitHub 作作品集副本

没有「最安全」只有「风险是否可接受」：公开项目怕消失 → 多镜像；私有项目怕账号 → 第二 remote + bundle；自建怕磁盘 → 异地第二份。

8收束

记住这几条

  1. 托管选的是协作生态，不只是磁盘——迁移成本常在 Issue/CI/权限，不在 git push。
  2. GitHub 仍是默认强选项，但值得配一条 backup remote 或定期 bundle。
  3. Gitea/Forgejo 适合「我要控制权、资源占用要低」的自建；NAS 适合内网主仓，别忽视公网与安全补丁。
  4. RAID 与云盘都不是备份；--mirror、bundle、LFS 卷备份要分开做。
  5. 恢复演练和备份本身一样重要。

Git 的分布式特性给了你退路——前提是退路提前铺好。先把权威 remote 定清楚，再叠镜像与离线包；比出事后再搜「GitHub 仓库 deleted 怎么办」省力得多。

9延伸阅读

注释

  1. GitHub Docs，Billing and usage。免费账户私有仓库标准 Linux Runner 约 2,000 分钟/月；公开仓库 Actions 不计入该额度（以文档当前说明为准）。 ↩

  2. GitHub Docs，Repository size limits。建议仓库控制在 1 GB 内，约 5 GB 可能收到警告；单文件超过 100 MB 会被拒绝。 ↩

  3. 同上。大文件需使用 Git LFS；LFS 免费档额度见 Git LFS billing。 ↩

  4. GitHub Docs，About billing for Git LFS。免费账户含 500 MB 存储与 1 GB/月带宽（整理于 2026 年 9 月）。 ↩

  5. GitLab，Free tier。免费档含私有仓库与有限 CI 分钟；具体分钟数与 Runner 类型以定价页为准。 ↩

  6. AWS，Discontinuation of support for AWS CodeCommit。2024 年 7 月起不再向新客户开放；现有客户需规划迁移。 ↩

CONTINUE EXPLORING

沿着这篇文章继续

在地图中查看
主题相近Git 大文件、Git LFS 与 Perforce主题相近主题相近Git 核心概念与实用技巧主题相近主题相近Git 客户端与工具推荐主题相近

Git 大文件、Git LFS 与 Perforce

Git 擅长管理文本与源代码，却在大二进制资产上容易失控。从 Git 为何「胖」、Git LFS 如何分流大文件，到 Perforce 为何长期占据游戏与影视管线，一文理清选型与落地要点。

从 VitePress 到 Fumadocs

记录用 Fumadocs、Next.js 和 Cloudflare Workers 搭建三个内容站的经验，以及我为什么从 Vue 转到 React。

On this page

1先分清：你在选什么2GitHub：默认选项，但不是唯一答案2.1适合的场景2.2需要知道的限制2.3实用建议3自建 Gitea：轻量、够用、自己负责 uptime3.1为什么选 Gitea 而不是 GitLab3.2典型部署形态3.3Gitea 的短板4NAS 当 Git 服务器：顺手，但有边界4.1常见实现4.2优点4.3缺点与坑5其他方案速览5.1SaaS 替代5.2自建重量级5.3与「代码托管」相邻的选择6备份：Git 分布式，但远程仍可能全丢6.1原则：3-2-1 的 Git 版6.2手段一：多 remote 镜像6.3手段二：git bundle 离线包6.4手段三：裸仓库克隆 + 存储快照6.5手段四：别漏 LFS 与元数据6.6恢复演练7怎么选：一张决策表8收束9延伸阅读注释