我剛開始將一些儲存庫從 GitHub 遷移到 Codeberg。我已經想這麼做很久了，但一直拖延，因為我認為 Codeberg 還沒準備好，而且遷移過程會是很多（無聊的）工作。
事實證明，這只部分正確，而且很大程度上取決於你的專案。如果你和我處於類似的狀況，希望這些筆記能作為你開始的動力和起點。這些解決方案可能不是我長期會堅持的，但它們是我認為從 GitHub 遷移時最容易開始的方法。
首先，是問題、拉取請求和發行版及其構件的遷移。這實際上是最簡單的部分，因為 Codeberg 提供從 GitHub 匯入儲存庫的功能，而且效果很好，所有這些功能的使用者介面幾乎與 GitHub 的相同。匯入會保留問題編號、標籤和作者身份。使用者體驗遠遠優於人們用來將其他問題追蹤器匯入 GitHub 的極其笨拙的技巧。
如果你使用 GitHub Pages，可以使用 codeberg.page。雖然它警告說不提供任何正常運行時間 SLO，但我從未注意到任何停機時間，目前來說還可以。你將 HTML 推送到一個分支，這與舊的 GitHub Pages 非常相似。更新 2025-09-22：或者你也可以嘗試 https://grebedoc.dev 或 https://www.statichost.eu/
到目前為止最棘手的部分是 CI。GitHub 在吸引人們使用免費的 macOS 執行器和公共儲存庫的無限容量方面做得非常出色¹。你將不得不放棄這兩樣東西。我建議針對你的程式語言進行交叉編譯，並為 Forgejo Actions 自架執行器，分別解決這些問題。
為什麼是 Forgejo Actions 而不是 Woodpecker CI？在 Codeberg 上的 Woodpecker 是否更穩定？是的，絕對是。事實上，Codeberg 上 Forgejo Actions 的文件目前已經過時了，但從 GitHub Actions 過來的 Forgejo Actions 會讓你感覺更熟悉。使用者介面和 YAML 語法幾乎相同，現有的 Actions 生態系統在 Codeberg 上大部分都能正常運作。例如，我 GitHub Actions 工作流程中的 uses: dtolnay/rust-toolchain 會在我的 Forgejo Actions 工作流程中變為 uses: https://github.com/dtolnay/rust-toolchain。
如果你絕對需要 macOS 執行器，我建議繼續在 GitHub 儲存庫上使用 GitHub Actions，將所有提交從 Codeberg 鏡像到 GitHub，並使用 Forgejo Actions 輪詢 GitHub API 並將 CI 狀態同步回 Codeberg。我還沒有嘗試過這個方法，但我嘗試過其他提供 macOS 建置的 CI 提供商，我認為它們與 GitHub Actions 整合到 Codeberg 中並沒有更容易或更乾淨。
最後，舊的 GitHub 儲存庫該怎麼辦？我剛更新了 README 並封存了該儲存庫。
你可以告訴 Codeberg 將新的提交推送到 GitHub，但這會讓使用者仍然可以提交 PR 並評論問題和提交²。有些人透過在 GitHub 儲存庫上禁用問題來處理這個問題，但這是一個非常破壞性的操作，因為它會導致所有問題都出現 404，而且無法禁用拉取請求。像 libvirt/libvirt 這樣的儲存庫編寫了一個 GitHub Action，可以自動關閉所有拉取請求。
這本身對自架和更廣泛的軟體生態系統會產生一些嚴重的後果，因為人們沒有動力去優化他們的建置或從你的網站下載發行版 tarball 的頻率。↩︎
在過渡期間，你可能仍想維護一個唯讀鏡像，或者繼續使用 GitHub Pages 和 GitHub Actions。↩︎