ハクソク

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

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

60日前原文(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が合理的ではない。」なんで？ツールが別々でも、両者の統合があれば問題ないチームはたくさん知ってるよ。

└

CIの盛り上がりが理解できないし、Gitなしでそんなものを動かすのが不可能だって言われるのも納得いかない。確かに、いいインターフェースは大事だけど、もっとシンプルなもので十分だよ。機能がたくさんあっても、実際のCIって何なの？リモートマシンで実行されるコマンドのセットで、その出力がブラウザに表示されて、他のコマンドの実行にも影響を与えるだけじゃん。何がそんなに大事なの？必要なら内部で作れるし、そんなにgitに依存する必要もないと思う。gitはフックを使ってトリガーできるけど、それだけだよね？本当の問題は、より良い結果をもたらすとされる複雑なプロセスを売りつけられたことだと思う。実際には、多くの人や組織にとってはただのカゴ文化みたいなもので、Kubernetesの例を挙げれば分かるけど、90%は取り除いても大丈夫だよ。5〜7人のチームならCIなしでも全然やっていけると思う。ちゃんとしたルールを作って、みんなに守らせればいいんだ（例えば、PRを出す前にユニットテストを実行するとか）。

└

こんな現代的なレイヤーで作業してると、なんでみんなそんなに気にするのか分からない。これは全部、中央集権化するための上層部の決定で、彼らはコントロールを保ってる気になってるだけだよ。開発者としては、これらのひどいリモートサービスのレイヤーがなくても、少なくとも同じくらい快適に過ごせる自信がある。

GitHubは「無料」でたくさんのことを提供してくれるけど、その代わりにデータを収集するのは全然気にしないよね。プライベートリポジトリでもトレーニングしてるんじゃないかって思う。オプトアウトできるけど、オプトアウトがうまくいかなかったらどうしようもないし。逆にCodebergはプライベートリポジトリを全く作れないから、CopilotがあなたのオープンソースのCodebergリポジトリを合法的にスクレイピングすることもあり得る。ほとんどの人にはあまり意味がないと思う。https://docs.codeberg.org/getting-started/faq/ >「商業プロジェクトのためにプライベートリポジトリが必要な場合（例えば、会社を代表している場合や、クライアントのためにプライベートなフリーランスプロジェクトをホストするスペースが必要な場合）、Forgejoを検討することを強くお勧めします。ForgejoはCodebergが運営するGitホスティングソフトウェアで、無料ソフトウェアであり、比較的簡単に自己ホストできます。Codebergはプライベートホスティングサービスを提供していません。」

└

「一方で、Codebergはプライベートリポジトリを全く作れないよ。」それ、本当にそうなの？Codebergのリポジトリは全部プライベートだと思ってたけど、間違ってるかも。

Codebergが嫌いなわけじゃないけど、"本当の" GitHubの代替とは言えないね。GitHubのリポジトリのかなりの部分（特にしっかりしたFOSSプロジェクトのためのもの）を扱えるけど、公開リリースやサポートを意図していないコードプロジェクトを置くための一般的な場所を探しているなら、あまり向いてないんだ。FAQによるとプライベートリポジトリは推奨されていなくて、制限も多い（最大100MB）。それに、ホームページをホストすることも望んでないから、GitHub Pagesを使ってた人には代替にはならない。残念ながら、そのジレンマを解決する答えは、自分でGitサーバーを立てて、その運用のオーバーヘッドを受け入れること以外にはないと思う。少なくともForgejo（Codebergの背後にあるソフトウェア）はFOSSだから、それを使ってほとんどのニーズをカバーできるはずだし、サーバーを持つならPages的な代替も簡単だよね。Gitlab.comもありかもしれないけど、Gitlabの「メイン」インスタンスが機能に関してどう変わったかはあまり知らない。これに関するFAQもあるから、読んでみる価値はあるよ。https://docs.codeberg.org/getting-started/faq/

└

「彼らはあなたのホームページをホストしたくないので、GitHub Pagesが理由でGitHubを使っていたなら、彼らは代わりにはならないよ。」https://docs.codeberg.org/codeberg-pages/

自ホストのForgejo（Codebergが使っているやつ）を仕事以外のプロジェクトに使ってるけど、すごくいいよ。GitHubが全然恋しくない。Tailscaleからだけアクセスできるようにしてるから、AIクローラーとかがすぐに入ってこれないようにしてる。

└

同じく。2ヶ月前にGitHubがエージェントアカウントを作らせてくれなかったからForgejoをインストールしたけど、最高だよ。新しい機能が欲しいときは、サーバー上のエージェントを開いて、Forgejoにその機能を追加するように言うだけ。PRレビューで「表示済み」ファイルを表示/非表示にする機能を追加するのに15分もかからなかったよ。

└

同じく！俺もdocker経由でforgejoランナーをインストールしたから、CIがあるよ。Forgejoには自分のアーティファクトリ/レジストリがあるから、作ったアプリがdockerイメージになって、それを実行するだけ。全部自分のハードウェアでやってる。

└

数年前にForgejoをセルフホスティングに移行したんだけど、すごくおすすめだよ。調子いいし。チュートリアルも投稿したし[1]（先月確認したけど、まだ動いてるよ）、最近はHetznerから2台のRaspberry Piにサーバーとランナーを移したんだ[2]。すごくいい。ほんとに安定してるし、GitHubよりも信頼性が高くて速いよ。[1]: https://huijzer.xyz/posts/55/installing-forgejo-with-a-separ... [2]: https://huijzer.xyz/posts/55/installing-forgejo-with-a-separ...

└

同じく！最近、fly.ioのプロキシを通して自分のもインターネットに公開したんだけど、今のところ問題はないよ。注意深く見守ってるけど。

└

giteaを選んだんだけど、同じような理由からだよ。実際に世界と共有したいものをGitHubにミラーリングするオプションが気に入ってる。特にForgejoを選んだ理由は何かある？プラットフォームを移るのはあまり気が進まないけど、最初にgiteaを立ち上げた時から、いろんな選択肢が増えてるのは知ってる。

なんで？理由を知りたいんだけど。原則的なこと？いくつかのサービスは基盤的な存在になっちゃって、他のことに移行する必要があると思う。例えば、GitHubを置き換えるとしたら、新しい習慣を作るためだよね。単に同じものを置き換えるわけじゃない。それじゃうまくいかない。新しいコードホスティングプラットフォームは何を提供してるの？アプリ開発と組み合わせれば、すごくいいものができると思う。でも、ただ別の場所にホスティングするだけじゃ、GitHubがSourceForgeやセルフホスティングから進化したような大きな変化が必要だよね。社会的な側面やgitの力がそれを推進してたから。個人的には、コードホスティングとアプリ開発をGoogleドキュメントみたいなエージェントを使って絡める必要があると思う。変更があるたびにコミットが発生する。プロンプトごとにコミットができる。よくわからないけど、何もないところで車輪を再発明する必要はないよね。

└

新しいコードホスティングプラットフォームは何を提供してるの？俺にとっては稼働時間を提供してるよ。最近のGitHubは、可用性がほとんど1%も達成してない。

└

なんでこの投稿があるの？おそらく、トレンドになってるCopilotの話と、それに伴う信頼の失墜が理由だと思う。GitHubに真剣な代替があるかは分からないけど、移行したい気持ちは「何もない」わけじゃないよね。

実際のところ、OSSプロジェクトをGitHubに公開してるのは、そこにコミュニティがあるからなんだ。問題やプルリクエスト、ディスカッションはおまけみたいなもん。コードを単にホスティングしたいだけなら、自分でホストするか、SSH/SFTPサーバーをgitのリモートとして使えばいいし、普段はそうしてるよ。

└

OSSプロジェクトをGitHubに公開してるのは、そこにコミュニティがあるからなんだ。 そうやって、私たちは永遠に同じところをぐるぐる回るんだろうね。既存のコミュニティがどこにあろうと、他のプラットフォームに移る人が増えれば。GitHubが初期の頃にコミュニティを見つけたのと同じように、ほとんどの人が（私の知る限り）SourceForgeを使ってた時代があったし。「コミュニティ」は、みんなが「コミュニティ」がいる場所にコードをアップロードする限り、ずっとGitHubに残るよね。もし十分な人がデフォルトでGitHubを使うのをやめて、別のものを使うようになれば、最終的には「コミュニティ」もそこにいることになるけど、これはちょっと鶏と卵の問題だと思う。私は他の人のためにソフトウェアを書くって考えを捨てて、自分のためだけに書いてるから、もし誰かが欲しいなら、私の個人のGiteaインスタンスに行って取ってくれればいいし、スターや「宣伝」とか、今の人たちが気にすることには全然興味ない。だけど、私はすでにネットワークを持ってるからラッキーなんだ。他の人はまずGitHubでネットワークを築く必要があるかもしれないし、そうすれば似たようなことができるようになると思う。結局はうまくいくはず。

└

今の「コミュニティ」は、雰囲気コーディングのスラッププルリクエストを出す人や、コーディングしない人が問題で文句を言ってるから、GitHub以外のフィルターがどんどん良くなってるよね。もちろん、これは独立したコミュニティを持つほど大きなプロジェクトに主に当てはまるけど。

うちの会社をGitHubからGitLabのセルフホストに完全に移行したよ。今のところ順調。全部Tailscaleの裏で動かしてるから、GitLabのSSO税もないし、CIランナーはEKSとGPU付きのオンプレミスクラスタにある。もし同じことをやりたい人がいれば、気軽に連絡してね！

└

Forgejoも試してみた？もしそうなら、二つの違いは何？GitLabにセルフホストのオプションがあるなんて知らなかった。おそらくエンタープライズ向けのプロジェクトやCI/CD、アクションなどに向いてるんだろうけど、問題やPR、ちょっとしたテストスイートだけの小さなプロジェクトにはForgejoが軽量でいい選択肢だと思う。

一番厄介なのはCIだね。GitHubは無料のmacOSランナーとパブリックリポジトリの無限の容量で人を引き寄せるのが上手だった。この点が私にとっても最大の障害だったんだけど、最近までCodebergをサポートするマネージドCIがなかったから。NixCI[0]が最近Codebergのサポートを追加して、すごく良い体験をしてる。唯一の難点は、CIをNixで書かなきゃいけないことだけど、LLMのおかげで実際には結構簡単だよ。私のCIジョブのほとんどは、ちょっとしたNixの設定があるbashスクリプトだし。[1] これで、コードを変更せずにローカルで全てのCIジョブを再現できるってことだね。[0] https://nix-ci.com [1] https://codeberg.org/mtlynch/little-moments/src/commit/d9856... - 例えばね。

Codebergのことは聞いたことないな。GitHubから乗り換える理由って何があるの？