ハクソク

世界を動かす技術を、日本語で。

「怠け者のためのGitHubからCodebergへの移行」

2026年3月26日原文(unterwaditzer.net)

概要

GitHubからCodebergへのリポジトリ移行体験談。 移行作業の難易度とポイントを解説。 イシューやリリースの移行は簡単。 CIやGitHub Pages代替の注意点。 移行後のGitHubリポジトリ管理方法にも言及。

GitHubからCodebergへのリポジトリ移行メモ

  • Codeberg へのリポジトリ移行を最近開始
  • 長年移行を考えていたが、 Codebergの準備不足 や作業量の多さを理由に先延ばし
  • 実際はプロジェクトによって難易度が大きく異なる

イシュー・プルリク・リリースの移行

  • Codeberg はGitHubからの リポジトリインポート機能 を提供
    • イシュー番号、ラベル、著者情報の維持
    • UIもGitHubとほぼ同じで、 移行ハードルが低い
  • 他のイシュートラッカーからGitHubへの移行よりも圧倒的に簡単

GitHub Pagesの代替

  • codeberg.page で静的サイト公開が可能
    • HTMLをブランチにプッシュする運用、GitHub Pagesとほぼ同様
    • SLO（稼働率保証）は未提供 だが、現状ダウンタイムは未体験
  • 代替案として grebedoc.dev や statichost.eu も利用可能

CI（継続的インテグレーション）の課題

  • GitHub Actions は無料macOSランナーや無制限のパブリックリポジトリCIが魅力
    • Codebergではこれらを 諦める必要
  • Forgejo Actions の自前ランナーを推奨
    • UIやYAML構文がGitHub Actionsに酷似
    • 既存のActionsエコシステムもほぼそのまま利用可能
    • 例：uses: dtolnay/rust-toolchain → uses: https://github.com/dtolnay/rust-toolchain
  • Woodpecker CI は安定しているが、GitHubからの移行には Forgejo Actions のほうが馴染みやすい
  • macOSランナーが必須の場合はGitHub Actions継続利用＋Codebergとの ミラーリング運用 を提案

移行後のGitHubリポジトリ管理

  • READMEを更新し、 リポジトリをアーカイブ
  • CodebergからGitHubへ新規コミットをプッシュ可能だが、PRやイシューの投稿が可能なまま
  • GitHubリポジトリのイシューを無効化すると 全イシューが404化 し、PRは無効化不可
  • 一部プロジェクト（例：libvirt/libvirt）は PR自動クローズ用GitHub Action を導入
  • 一時的な read-onlyミラー 維持や、GitHub Pages/Actionsの継続利用も選択肢

CI・ホスティング移行に伴うエコシステムへの影響

  • GitHub依存のビルドやリリースダウンロード最適化への モチベーション喪失
  • ソフトウェアエコシステムの 自己ホスティング推進 課題
  • 移行期間中の read-onlyミラー 運用や、必要に応じたGitHubサービスの部分利用推奨

Hackerたちの意見

怠けてるわけじゃないけど、Codebergは単に動かないんだよね。Codebergを使ってる友達はみんなCloudflareに反対してるけど、実際CloudflareがGitlabを支えてるのが現実なんだよ。攻撃されまくってるから、何かしらのDDoSフィルターが必要なんだ。今はAnubisみたいなものがあるらしいけど、それでもダウンタイムがあるし、開発者として一番辛いのは、コーディングしたいのにリモートにアクセスできないことなんだよね。これがCodebergの印象を台無しにする。正直に言ってごめん。大きな独占企業の競争相手には成功してほしいけど、自分の仕事や情熱も続けたいんだ。

└

もしかしたら古い考えかもしれないけど、GitHubもCodebergも、私にとっては非同期的な「なんとかしてコードを送信/共有したい」って感じで、「仕事をするために必要なアクティブな作業スペース」ではないんだ。でも、>開発者として一番辛いのは、コーディングしたいのにリモートにアクセスできないこと。これを読むと、GitHubやCodebergがオンラインじゃないとコーディングできないみたいに思えるけど、本当にそうなの？もしそうなら、どうやってそんな状況になるの？GitHubのウェブUIで直接コードを編集する以外にどうするの？

└

私も同じ経験をしたことがある。哲学的には、Cloudflareがインターネットの大きな部分で仲介者になってしまったのはひどいことだと思う。ユーザーとしては、私の生活をかなり悪化させてる。ブラウザの制限やVPNで自分を守る能力が制限されて、普通にブラウジングしてるだけなのに、何も攻撃してないのにね。でも実際には、ウェブマスターや管理者としては、Cloudflareはほぼ必需品なんだ。99%以上のトラフィックがボットで、しばしば脆弱性をスキャンしてるボットばかりだから、Cloudflareの背後に置くようにしてる。PHPサイトはほとんどないのに、トラフィックログは/admin.phpや/wp-admin.php、WordPress関連のリクエストで埋まってるし、明らかに検索エンジンじゃないクローラーがすべてをダウンロードして、robots.txtをクロールするためのガイドとして使ってる。まだDDoS攻撃は受けてないけど、画像やPDFが何度もダウンロードされて、結局お金がかかってる。私や家族だけが正当なユーザーのものに関しては、自分のIP以外をすべてブロックすることができるけど、それでもメンテナンスが面倒なんだ。いくつかの代替を試したけど、正当なユースケースでも失敗することが多い。Cloudflareよりも代替にブロックされたことの方が多いし、特にプルーフ・オブ・ワークをするやつは、80%の確率でうまくいくけど、その20%が本当にイライラする。あの画面が出ると、すぐに別のサイトに移動しちゃう。今の状況は本当に落胆するよ。ここ数年で、自分の信念や価値観が試されたことはないと思う。

└

自分のGitサーバーはスクレイパーにひどく攻撃されてる。彼らはすべてをスクレイピングしてる。コミット、コミット間の比較、ファイルのAPIコール、すべて。ByteDance、OpenAI、AWS、Claude、他にもいろいろ分からないものがほとんど。合理的なパフォーマンスを得るために、すべてをブロックするしかなかった。Codebergに移行しようと思ったこともあったけど、その時にダウンタイムがあったから、自分で対処する方がいいと思った。

└

Gitの本質は分散型にあるから、リモートがオフラインでも現在のバージョンを持っておく理由は全くないよね。

└

でも、まだダウンタイムがあるんだよね。神様、GitHubは…ああ。 https://mrshu.github.io/github-statuses/

└

たぶんどこかで起こったことはあると思うけど、個人的にはCodebergのダウンタイムにはまだ遭遇してないな。こないだ、GitHubがまたダウンしてたけど。GitLabはしばらく使ってなかったけど、使ってた時は問題なかったし、CIもGitHubよりはまともに見えるけど、GitLabも使い勝手がいいわけじゃないしね。まあ、CodebergにはGitLabで使ってた機能が全部あるわけじゃないけど、自分のプロジェクトにはあんまり必要ないかな。

└

OPはGitHubについてだよね。GitHubの稼働時間モニター見たことある？過去90日間で90%[1]だよ。CodebergとGitHub両方をよく使ってるけど、GitHubはCodebergよりも問題が圧倒的に多い。Codebergで遅くなることもあるけど、それくらいかな。[1] https://mrshu.github.io/github-statuses/

└

[遅延]

GitHubの代替を評価することが、これからの数年間でますます重要になると思う。だけど、こういう移行がGitHubがどれだけテーブルの基準を変えたか、価値あるソースフォージの条件を引き上げたかを過小評価してると思う。今や、BYO CIを持ち込むのは現実的じゃないし、一般的なエンドユーザーアーキテクチャ向けにネイティブにビルドできないものを受け入れるのも無理なんだ。これだけでも、GitHubを追い出そうとするコミュニティ主導の試みに対してはあまり期待できないな。イデオロギー的には共感してるけど、2026年のソースフォージに対するユーザーの期待の実際のコスト（財政的にも複雑さの面でも）は膨大なんだ。

└

CIはソースフォージに良い統合が必要だよね。でも、GitHub ActionsがみんながCircleCIとかを設定してた頃よりも大きな利点だとは思わない。PRチェックが赤、黄、緑に変わって、ログへのリンクがあれば満足だよ。PRやコードレビューの体験の方が私にとってはずっと重要なんだ。GitHubは高い基準を設定しようとしてるけど、いくつかの点では本当にひどい。全体の問題システムもGitHubではまあまあだけど、20年前の問題システムの最先端には達してないよね。

└

「もはやBYO CIが合理的ではない。」なんで？ツールが別々でも、両者の統合があれば問題ないチームはたくさん知ってるよ。

Hacker Newsで議論の続きを見る