本篇文章更新時間：2026/03/27
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
從 GitHub 搬家到 Codeberg：一篇給「遲遲不敢動手的人」的實戰心得
編輯前言：這篇文章對我最大的啟發，是讓我發現「從 GitHub 搬去 Codeberg 其實並沒有我以為的那麼可怕」。如果你也想擺脫平台鎖定、回到更自由的開源環境，這篇非常值得一讀。
文章來源：Moving from GitHub to Codeberg, for lazy people
核心觀點 (Key Takeaways)
- Codeberg 的 GitHub 導入工具成熟、完整，issues、PRs、labels、authors 都能無痛搬家。
- GitHub Pages 可直接改用 codeberg.page，替代方案也逐漸成熟。
- 最麻煩的部分是 CI——你將失去 GitHub 的 macOS runners 與免費資源，需要調整策略。
深入解析
原文作者一開始坦承，遲遲不行動是因為覺得 Codeberg「還不夠成熟」「搬家很麻煩」。但實際開始動手後，才發現其中有不少部分其實比預期順利。
作者指出：「Codeberg offers repository import from GitHub that just works.」
對我而言，這是最關鍵的句子，因為它直接消除技術門檻。
1. 儲存庫與 Issues/PRs 搬遷：完全無痛的驚喜
作者特別強調 Codeberg 的匯入工具出乎意料地成熟：
- 可自動保留 issue 編號
- labels、作者、PRs、releases 都能完整帶過來
- 操作介面跟 GitHub 幾乎一樣
這點讓我想到許多人從 GitLab 或其它平台轉進 GitHub 時的麻煩——Codeberg 顯然走在一條「不折磨使用者」的路上。
2. GitHub Pages 的替代方案：codeberg.page 很好用
如果你和我一樣有用 GitHub Pages 做靜態網站，那遷移一定是個疑慮。作者推薦的 codeberg.page 其實相當直覺：
- 同樣是把 HTML 推到一個 branch
- 基本沒遇過 downtime
此外作者補充了幾個替代：grebedoc.dev、statichost.eu，顯示整個生態系其實正在成形。
3. 最棘手：CI 遷移與 macOS Runners 的缺席
這段是原文最具「現實含量」的部分。
GitHub Actions 免費、macOS runner 可用、公共 repo 幾乎無限制，這些都是開發者長期被寵壞的地方。
作者指出：
「You will have to give up on both of those things.」
也因此，作者的建議是：
- 改用 cross-compilation 減少對 macOS runner 的依賴
- 自架 Forgejo Actions runner
為什麼是 Forgejo Actions？因為：
- YAML 語法跟 GitHub Actions 幾乎一樣
- 大多數 Actions 生態可以直接用
- UI 也相當熟悉
例如：
uses: dtolnay/rust-toolchain
只要改成：
uses: https://github.com/dtolnay/rust-toolchain
這種兼容性對遷移非常重要。
4. GitHub 上的舊 Repo 怎麼辦？
作者選擇：
- 更新 README
- 直接 Archive
原因是：
- 若 Codeberg 自動 push 回 GitHub，用戶仍能在 GitHub 留 PR、開 issue，導致兩邊混亂。
- 關閉 GitHub issues 會讓所有 issue 直接變成 404，非常破壞資訊價值。
有些專案甚至用 GitHub Action 自動關閉所有 Pull Requests，但這種「反操作」其實也不太友善。
筆者心得與啟發
讀完這篇文章，我最大的感觸是：「遷移開源平台不是技術問題，而是習慣問題。」
GitHub 的確方便，但也因為太方便，讓我們忽略了平台鎖定的風險。作者的經驗提醒我：
- 生態系確實在成長（例如 Forgejo、codeberg.page）
- 遷移的痛點其實比想像中少
- CI 是唯一的大難題，但也不是無法克服
如果你也想尋找更自由透明的開源託管，或是不想讓專案永遠依附在 GitHub 商業策略底下，我會建議從最簡單的步驟開始：
先把 repo 匯入 Codeberg，看看自己的開發流跟新平台是否合拍。
不用一次跳水，也不用一次搬完，只要開始動手，就會發現門檻其實比你想像中低。