- 個人プロジェクトとウェブサイトをGitHubからCodebergへ移行した過程と結果を具体的に説明
- Forgejoの「migrate from GitHub」機能を使って、リポジトリ、Issue、PR、Wiki、リリースを完全に移行
- リンク再割り当てとGitHubリポジトリのスタブ処理を自動化スクリプトで実施し、移行済みであることを明確に表示
- CI/CDの移行ではCodebergのForgejo Actionsを活用し、環境制約に合わせて軽量化したワークフローを構成
- ウェブサイトはgit-pagesとGrebedocを使って無停止で移行し、全体のマイグレーションを週末内に完了
マイグレーション概要
- GitHub Pagesでホスティングしていたサイトと45のリポジトリをCodebergへ移行
- 単純なクリック操作で終わるわけではなく、複数段階の手作業が必要だった
- 全体のプロセスは週末の間で完了し、支障なく進められた
- このプロセスで、他の開発者も簡単に移行できることを示すことを目的とした
1段階: リポジトリの移行
- CodebergはForgejoベースで、「migrate from GitHub」機能を提供している
- GitHubで**Personal Access Token(PAT)**を発行し、Issueなどのメタデータをまとめて取得可能
- GitHub APIのrate limitのため、同時に複数のリポジトリを取り込むと失敗することがあった
- Issue、PR、Wiki、リリースが完全に移行され、GitHub参照が不要になった
2段階: リンク再割り当て
- ローカルリポジトリ内のGitHubリンクをCodebergのアドレスへ一括変換
sedとfindコマンドを使ってテキストベースで自動置換
- 各リポジトリの
git remote URLもCodebergに変更したうえで、すべてのリポジトリへプッシュ
3段階: GitHubリポジトリのスタブ処理
- GitHubリポジトリに移行告知用READMEを追加し、説明文とホームページリンクをCodebergに修正
- 自動化スクリプトを作成して複数リポジトリに一括適用
gh repo archiveコマンドでリポジトリをアーカイブ処理
4段階: CI/CDの移行
- CodebergのCIドキュメントではエネルギー消費を最小化する原則が強調されている
- そのためCIが本当に必要なプロジェクト（ウェブサイト、ドキュメントビルドなど）のみを残す
- CodebergはWoodpeckerとForgejo Actionsの2種類のCIを提供
- GitHub Actionsに近いForgejo Actionsを選択
- 主な違い
- ほとんどのActionsはそのまま動作
- Linux専用ランナーのみ提供され、macOS・Windowsは未提供
- インストール済みソフトウェアが少なく、リソースが制限的
- lazy runnersを使うことで負荷分散と省エネ実行が可能
- CI性能向上のためLaTeX事前インストール済みのDockerイメージを使用したが、バージョン問題で標準のUbuntuイメージに戻した
5段階: ウェブサイト再ホスティング
- GitHub Pagesで運用していたサイトをCodeberg Pagesへ移行しようとしたが、当該機能はメンテナンスモード
- 代替としてgit-pagesとGrebedocを見つけて利用
- DNS変更前のアップロード対応により無停止切り替えが可能
- サーバー側リダイレクトとカスタムヘッダに対応
- 既存リンク（
eldred.fr/fortISSimO）を維持したまま移行完了
- Codebergは今後git-pagesへの段階的移行を計画
- GitHub Pagesより満足度が高く、git-pages開発者のPatreon支援に参加
時間
- リポジトリ移行（1〜3段階）：半日
- CI移行（4段階）：半日
- ウェブサイト移行（5段階）：技術的負債の整理を含めて数日かかった
- 全体として週末内に完了、想定より簡単な作業だった
マイグレーション後
- ウェブサイトの機能に異常なし。GitHubのmasterブランチのみ残した
- GitHubリポジトリ削除はリダイレクト欠如のため保留
- GitHubアカウントは他プロジェクトへの貢献のため保持
- Codebergへ移行するとコントリビューター数が減る可能性はあるが、すでにCodebergアカウントを作成して継続的に貢献しているユーザーもいる
謝辞
- Catherine ‘whitequark’： git-pagesおよびGrebedocの運営
- SERVFAIL networkチーム：DNS提供
- CodebergおよびForgejoのコントリビューター：移行基盤の提供
1件のコメント
Hacker Newsの意見
今回の移行の話で目立つのは技術的な部分ではなく、
feature parityが本当の障害ではないという点Codebergは日常的なワークフローには十分だが、GitHubが積み上げてきたネットワーク効果と慣性が足りない
Blueskyのようなプロトコルをベースに、Gitがどこでホスティングされていてもアイデンティティと接続性が保たれるよう設計されている
前に確かに見たIssueを見つけ直すのが難しい。性能は最近かなり良くなったが、数百件のIssueがあるプロジェクトならテスト移行を先に試したほうがいい
CI/CDのようなものはチーム全員が理解する必要はなく、1人が詳しければ十分
CodebergはGiteaのフォークで、GiteaはGogsのフォーク
どちらのフォークも技術的理由より思想的理由で始まり、Gogsを作ったJoe Chenの功績は大きい
Giteaは1人の開発者がリポジトリ権限を独占したことでフォークされ、ForgejoはGiteaの商標権を取り戻すために作られたフォーク
CodebergとF-Droidを一緒に使ったことがある人がいるのか気になる
GitHubのように自動でリリースを検出できるのか知りたい
いまや**臨界点（threshold effect）**に達したようだ
ここ数日で複数のプロジェクトがGitHubから離脱するのを見た
何か出来事やトレンドがあるのか気になる
オープンソースコミュニティの不満が積み重なり、限界点に達したようだ
Microsoft全体のAI・広告化をめぐる論争やWindows 10のサポート終了も影響していそうだ
関連する概念は このTwitterスレッド で最初に提示された
以前のRailsベースだった頃のほうが良かった気がする
実際以上に注目されている一時的な現象かもしれない
GitHub代替の中で、小規模チームや個人開発者に向いたものがあるのか気になる
CodebergはFOSS中心なので商用用途には向いていないように見える
GitLabは高機能だが保守が重い
そのほかにもGitea、Gogs、PhorgeなどさまざまなFOSS forgeがある
GitHub UIをコピーせず、ローカルのように速い即応的なインターフェースが気に入っている
「Microsoftが嫌い」という理由だけで移る必要はない
結局Codebergに新しいプロジェクトを置き、一部はGCPでプライベートミラーとして維持している
関連して Ask HNスレッド を立てたが反応はなかった
eldred.frのブログ記事 を見ると著者の理由はもっともだが、ユーザーの立場では体感できる改善がほとんどない
Codebergを使ってみると
例: https://codeberg.org/dnkl/foot
READMEをメインページにしたほうがよさそう
有料版では画像のカスタマイズも可能
あまりに違うものにすると、かえって反発が大きい
GitHubログインボタンを隠したのはコミュニティ主導の判断で、望むならPRで提案することもできる
GitHubと同じ機能を持ちつつ、倫理的な代替を求めていた
GitHubでのAIスキャンが問題でないなら、政治的でない理由で移る必要があるのか気になる
Codebergが無料CIランナーを提供しているのか気になる
GitHubは年間1億ドル以上をCIに使っていると推定される
ただ、環境コストを持ち出すのは、むしろユーザー参加をためらわせるかもしれない
技術者には性能最適化の問題として語るほうが効果的だ
Codebergが以前、スパム事件を「極右のヘイトキャンペーン」として大げさに扱い、自画自賛していたのを見て失望した
単に予防に失敗したと認めればよかったのに、政治的フレームで包んでいた
関連リンク: Issue, HN議論, ブログ記事
そのことで敬意を失ったのなら、問題はプロジェクトではなくその見方のほうにある
私も以前、Codebergにリポジトリを移したあとで再びGitHubに戻ったことがある
GitHubのさまざまな機能が気に入っているわけではないが、Codebergには協業を引き寄せる力が足りない
単独メンテナーとしては可視性とネットワーク効果がどうしても重要だ