【ITニュース解説】How I migrated from GitHub to Codeberg

プログラムコードを保存し、管理する場所を「リポジトリ」と呼ぶ。GitHubは有名だが、時には別のサービスへ移行する選択肢もある。今回解説するのは、GitHubからCodebergという別のプラットフォームへプロジェクトを移行した事例だ。この移行には明確な理由があり、その手順や移行によって得られるもの、失うものについて詳しく見ていこう。

まず、なぜGitHubからCodebergへ移行しようと考えたのか。最も大きな理由は、GitHubが「プロプライエタリ」なプラットフォームであるという点にあった。プロプライエタリとは、特定の企業が独占的に所有し、運営するという意味である。多くの公開されたコードがGitHubに集まる中で、GitHubが提供するAIアシスタント「Copilot」が、これらの公開コードを学習データとして利用していることに対し、自分のコードの「主権」、つまり自分のコードがどのように扱われるかという点について懸念を抱いた。自分のコードが知らないうちにAIの学習に使われたり、企業側の都合で利用されたりすることに不安があったのだ。Codebergはヨーロッパの非営利団体によって運営され、特定の企業の利益に左右されない透明性の高い運営が期待でき、主権の問題を解決できると考えた。

また、GitHubの機能の多さに疲弊し、もっとシンプルな環境を求めたことも重要な理由だ。GitHubには多くの便利な機能があるが、日常的な開発では使わない機能も多く、それがかえって複雑さを生み出していると感じた。Codebergでは、必要な機能に絞り込まれており、余計な情報に惑わされず、コード開発に集中できる環境を求めた。シンプルな環境は効率的な作業を可能にする。

次に、具体的なプロジェクトの移行手順について説明する。「Git」というバージョン管理ツールで管理されているコードを、GitHubやCodebergのようなサービスはインターネット上で保存・共有する場所、つまり「リモートリポジトリ」として提供する。

今回の移行は、以下の簡単なコマンドで行われた。 まず、「git remote set-url origin https://codeberg.org/NuxiPro/Core.git」というコマンドを実行した。このコマンドは、現在プロジェクトが連携しているリモートリポジトリのURLを新しいものに変更する命令である。「origin」はメインのリモートリポジトリを指す慣例的な名前だ。これにより、今後自分のパソコンからコードを送信する際、その送信先がGitHubからCodebergへと切り替わる。 次に、「git push --all」と「git push --tags」という二つのコマンドを実行した。前者の「git push --all」は、プロジェクト内のすべての「ブランチ」（開発中にメインのコードから一時的に派生させる作業の流れ）を新しいリモートリポジトリへ送信する命令である。後者の「git push --tags」は、「タグ」（特定のバージョンに目印をつけ、後から簡単に参照できるようにする機能）を送信する命令だ。これらのコマンドを使うことで、プロジェクトのすべての履歴や状態を丸ごとCodebergに移行できた。

Codebergには、既存のGitHubリポジトリを自動でインポートする便利なツールも用意されていた。しかし、移行するプロジェクト「NuxiPro Core」が「プライベート」、つまり非公開リポジトリだったため、確実性を重視し、手動でのコマンド操作を選択した。結果的に、この移行作業は数分で完了し、非常にスムーズだった。

この移行によって、開発者が得たものと失ったものを整理しよう。

得られたものとして、まず「日常のシンプルさ」がある。不必要な機能が排除されたことで、開発環境がすっきりし、より快適に作業できるようになった。次に「主権」の確保がある。Codebergは非営利団体によって運営されており、自分のコードが特定の企業の利益のために利用される心配が少ないため、安心感を持って開発に専念できる。これは「倫理」的な側面にもつながり、自分のコードが搾取されることなく、よりオープンな精神で利用される環境を選んだということだ。さらに、落ち着いた、クリーンな開発環境が得られたこともメリットだ。プロプライエタリなツールに依存せず、自由度の高い環境で開発を進められる。

一方で、失ったものもある。GitHubは世界中の多くの開発者が利用しているため、Codebergに移行することで、プロジェクトの「可視性」、つまり他の開発者の目に触れる機会が減る可能性がある。また、GitHubが提供するような、最初から組み込まれている便利なツールやサービスがCodebergには少ないかもしれない。しかし、これは必ずしもデメリットばかりではない。既成のツールが少ない分、自分で必要なツールを選び、追加できる「制御力」が高まる。自分の開発スタイルに合わせた環境を構築できるのだ。

さらに、このプロジェクトでは「Forgejoランナー」と呼ばれる、ソフトウェアのテストやデプロイ（完成したプログラムを配置すること）といった自動処理を行うツールを、自分のパソコン上で「自己ホスト」することにした。通常、これらの自動処理は、クラウドサービスやCodebergが提供する共有リソースを利用することが多い。しかし、自身のPCでランナーを動かすことで、Codebergの共有リソースをテストやデプロイ中に「飽和」させないように配慮し、自分のPCの能力を活用するメリットもあった。

ランナーの実行環境の分離には「Docker-in-Docker (DinD)」という戦略を採用した。Dockerはアプリケーションを隔離された環境（コンテナ）で実行する技術だ。DinD戦略では、そのコンテナの中にさらに別のDocker環境を用意し、テストやビルドのジョブを実行する。これにより、テスト環境が完全に隔離され、自分のパソコン本体に影響が及ぶことはない。高い「分離性」と「安全性」を確保しながら開発を進められる。将来的には、このランナーを自宅のPCではなく、専用のサーバーに移行することで、自分のPCに依存しない、より安定した自動処理環境を構築する計画がある。

最後に、デモ用のリポジトリについて補足がある。現在、一時的にGitHubに残されているデモ用のプロジェクトが存在するが、これは今後すぐに停止され、削除される予定だ。このデモは試験的なもので、維持管理に手間がかかるため、新しい形に置き換えられることになっている。最終的な削除前に情報が共有されるだろう。

今回のGitHubからCodebergへの移行事例は、単なるコードの移動だけでなく、プラットフォーム選択が持つ倫理的意味合い、開発環境をシンプルに、そして自身でコントロールしたいという願いを反映している。システムエンジニアを目指す上では、このようなプラットフォーム選択の背景を理解することも重要だ。