GitHub 代替7選：料金・CI/CD・移行の注意点から選ぶ【2026年】

GitHub 代替を幅広く検討するなら、最有力はGitLabです。自社で運用したい場合は、まずGiteaが候補に入ります。ここで紹介する7つのGitHub代替サービス・ソフトウェアは、マネージド型とセルフホスト型に分かれます。ただし、選定を左右するのはコードと一緒に何を移す必要があるかです。レビュー、Issue、CI/CD、アクセス制御まで含めて考えます。

2026年11月5日に各提供元の公開ページで確認しました。 本記事はドキュメントと料金の比較であり、実際に移行を試した検証記事ではありません。「利用可能」は、提供元が登録、購入、インストールのいずれかを受け付けているという意味です。アカウントの作成や契約承認まで確認したものではありません。

GitHub 代替サービス・ソフトウェアの比較一覧

提供元を選ぶ前に、運用形態を決めます。マネージドサービスでは、コードホスティング基盤の運用を提供元に任せます。セルフホストでは、インストール、バックアップ、復旧を自社で管理します。ビルドジョブを実行するCIランナーだけを自社運用しても、クラウドのコードホスティング自体がセルフホストになるわけではありません。

この料金は入口の価格であり、同じ内容のパッケージではありません。各節の料金リンクで提供元の条件を確認してください。ソフトウェアのライセンスが無料でもサーバー費用は発生します。リポジトリの契約にAIアシスタント、Issueトラッカー、無制限のビルド能力まで含まれるとも限りません。

コストだけを理由に移る前に、GitHubの現行料金と当サイトのGitHub料金解説を比較してください。移行が必要になった機能上の理由も書き出します。ユーザー単価が安くても、移行と保守の負担を含めると高くつく場合があります。

運用を任せられるGitHub代替サービス

開発インフラの稼働に責任を持つ担当者がいないなら、マネージド型を基本に考えるのが妥当です。リポジトリ権限の管理や専用ビルドマシンの運用は開発者が行い、ホスティングアプリケーションの保守は提供元に任せられます。この中では、開発全体を扱うプラットフォームと、特定のコミュニティやクラウドに合わせたサービスを区別することが重要です。

GitLab：開発全体を置き換える最有力候補

GitLabは、リポジトリ、Issue管理、マージリクエスト、CI/CDを統合する開発プラットフォームです。CI/CDはビルド、テスト、デリバリーを自動化する仕組みです。GitHubを離れてもコードレビューとデリバリーをまとめて扱いたい企業が、最初に評価すべき候補です。アプリケーションコード、バックログ、リリースパイプラインを持つチームなら、業務の一連の流れを同じ移行先で検証できます。ただし、プラットフォームの移行であることに変わりはありません。概念が似ていても、権限、自動化、過去の議論が同じ形で再現されるわけではありません。

向いているチーム： 相互につながった複数のGitHubワークフローを移す開発責任者。
特徴： リポジトリだけでなく、共同開発のメタデータも扱うGitHubインポーター。
料金： Freeは$0。Premiumは年払いで$29/ユーザー/月から。GitLab料金ページに記載されています。
無料トライアル： 継続利用できるFreeプランに加え、有料プランのトライアルがあります。

CI/CD・Issue・レビュー： いずれもプラットフォームに含まれます。マージリクエストはGitLabにおけるプルリクエスト相当の機能で、変更案をマージ前に議論します。GitLab.com Freeでは、トップレベルグループの上限は5ユーザー、コンピュート時間は月400分とされています。トップレベルグループはプロジェクトとメンバーをまとめる組織上の入れ物です。このホスティング版の枠を自社運用版に当てはめたり、専用の計算資源が確保されると考えたりしないでください。

AIコーディングアシスタント： GitLab Duoは、IDE拡張機能やGitLab画面での支援に加え、エージェントや自動化ワークフローを提供します。IDEは開発者がコードを書き、デバッグする開発環境です。利用範囲と使用量はプラン、導入形態、GitLab Creditsによって異なります。FreeのホスティングアカウントでDuoの全機能が無料になるわけではありません。Duoのドキュメントには対応モデルやAIゲートウェイのホスティングも記載されており、こちらは別途導入評価が必要です。

GitHubからの移行： GitHubインポーターのドキュメントは、リポジトリ、Issue、プルリクエスト、コメントなどのプロジェクトメタデータに対応しています。GitHubの組織やグループを、そのまま組織やグループとして移す機能ではありません。Markdownの添付ファイルは任意のインポート対象なので、移行元を早く削除すると過去のリンクが切れるおそれがあります。古い障害チケットに、本番障害を説明する唯一のスクリーンショットが残っているような場合に重要な違いです。

GitLabとGitHubの比較：選択を分ける判断軸

デリバリーと共同開発を統合する価値が、運用ワークフローを変える負担を上回るならGitLabを選びます。主な不満をアクセスポリシーや課金管理で解決でき、既存の連携にリリース工程が強く依存しているなら、GitHubを継続する理由があります。アシスタントへの不満から移行しても、移行先でDuoを有効にするか確認しなければ、根本のポリシー判断は解決しません。

試験移行には、問題を見つけられるだけの履歴があるリポジトリを選びます。コメント付きの完了済みレビュー、Issueの添付ファイル、稼働中のリリース工程を含めてください。ほぼ空のリポジトリでは、確認できることが限られます。開発者とリリース承認者が一緒に結果を確認すると、それぞれ異なる問題を見つけられます。

1. 1

   移行先と必要最小限のインポート権限を準備する

   移行先グループを作り、実行ユーザーに必要なMaintainerまたはOwnerロールがあることを確認します。GitLabを自社運用している場合は、GitHubをインポート元として有効にします。承認済みのOAuth接続、または文書化されたトークン方式を使い、権限を移行に必要な範囲に絞ります。

2. 2

   GitHubインポーターを実行する

   Create new、New project/repository、Import project、GitHubの順に選びます。アクセスを許可してリポジトリを選択し、開始前に移行先の名前空間と任意の添付ファイル設定を確認します。

3. 3

   共同開発の履歴を個別に検収する

   ブランチ、タグ、Issue、レビューコメント、添付ファイルを移行元と比較します。ユーザーの対応付けとアクセス権を明示的に確認してください。差異を解消する間はGitHubを利用可能な状態で残します。インポート完了は、過去のリンクがすべて機能する証拠にはなりません。

4. 4

   切り替え前にリリース経路を再構築する

   移行先のパイプライン、認証情報、リリース承認を設定し、リリースとロールバックを予行します。その後、新しい正本リポジトリを指定し、一時的な移行権限を削除します。GitLabのリポジトリミラーリングでは、その後のGitHubプルリクエストの変更は同期されません。

Bitbucket Cloud：Jira中心のチームで生きる選択肢

Bitbucket Cloudは、Atlassianが運用するリポジトリ・レビューサービスで、ビルドとデプロイにはPipelinesを使います。すでにJiraで開発計画を管理し、リポジトリの活動をその作業項目に結び付けたい企業に適しています。変更を、その理由となったタスクとつなげておける点が利点です。課題はIssue管理です。Bitbucket標準のIssuesとWikisは廃止されているため、各リポジトリに小さな独立トラッカーを添えたいという目的には適しません。

向いているチーム： Jiraのワークフローが定着しているチーム。
特徴： リポジトリとパイプラインの活動を作業管理に結び付けられます。
料金： 5ユーザーまで無料。Standardは$3.65/ユーザー/月から。Bitbucket料金ページに記載されています。
無料トライアル： StandardとPremiumのトライアルがあります。

CI/CD・Issue・レビュー： Pipelinesを統合しており、Freeプランのビルド時間は月50分です。プルリクエストとレビュアーに対応しますが、マージチェックの強制は有料プランを検討する項目です。Issue管理にはJiraなどのトラッカーを使う前提で考えます。AtlassianのIssuesとWikisの廃止告知には、2026年8月20日の削除が明記されています。

AIコーディングアシスタント： Atlassianはコーディング支援やコードレビューを含むRovo Devを提供していますが、提供形態は移行中です。Rovo Devの移行案内によると、単独製品は提供終了に向かい、Code Reviewerは対象のJiraおよびTeamwork Collection契約へ移り、CLIはRovo CLIへと発展します。確認したページでは、単独製品の最終的な終了日は確定していませんでした。自社に適用される利用権を確認してください。Bitbucketのユーザー契約に、従来どおりの単独アシスタントが自動的に含まれる前提で予算を組むべきではありません。

GitHubからの移行： Create、Repository、Import repositoryと進み、GitHubリポジトリのURLと必要な認証情報を入力します。Atlassianが文書化しているのはリポジトリインポーターであり、GitHubのIssue、レビュー、組織ポリシーの完全移行ではありません。それぞれ別の作業として扱います。

Jiraをすでに使うチームなら、GitHubのIssueを既存プロジェクトへ対応付ける作業は、整理の機会にもなります。一方、GitHub Issuesだけを使っていた小規模企業には、管理するシステムが新たに増える可能性があります。ユーザー単価を節約とみなす前に、Issueのリンクと過去の参照を誰が維持するか決めてください。

評価： Bitbucketの強みはAtlassianのワークフローにあります。Jiraを使いたくない場合、その利点は大きく薄れます。

Azure DevOps Services：計画管理とMicrosoft中心のデリバリーに強み

Azure DevOps Servicesは、Repos、Boards、Pipelinesを組み合わせたMicrosoftのホスティング型スイートです。GitHubの交流機能を再現することより、作業項目、リリース工程、組織管理を重視する場合に適しています。社内アプリケーションを開発する企業は、タスク、コード変更、デプロイの議論をスイート内にまとめられます。ただし、対応範囲には注意が必要です。Azure Reposへ移っても、Copilotという名前を持つ機能を含め、GitHub固有のすべての機能を引き継げるわけではありません。

向いている組織： 計画とデリバリーの基盤をまとめたい組織。
特徴： Boardsの作業項目をリポジトリやパイプラインの作業に結び付けられます。
料金： Basicは最初の5ユーザーが無料で、以降は追加ユーザーあたり$6/月です。Azure DevOps料金ページに記載されています。
無料トライアル： Basicの無料枠は継続利用できます。別途提供されるTest Plansのトライアルとは異なります。

CI/CD・Issue・レビュー： Azure PipelinesがCI/CD、Boardsが作業項目管理、Reposがプルリクエストを担います。公開されている無料のホステッドパイプライン枠には、並列ジョブ1件と月1,800分が含まれます。並列ジョブは同時に実行できるジョブ数の枠であり、待機中のビルドをすべて一斉に開始できる意味ではありません。現行の並列ジョブのドキュメントには、有効なAzureサブスクリプションを関連付けると、非公開プロジェクト向けの無料枠が有効になると記載されています。

AIコーディングアシスタント： Azure Repos向けGitHub Copilotコードレビューはパブリックプレビューです。組織・リポジトリ単位で制御でき、関連付けたAzureサブスクリプションを通じて課金されます。人間のレビュー前に変更コードへコメントできます。一方、Azure BoardsからCopilotに作業項目の実装を依頼する別の連携では、引き続きGitHubリポジトリが必要です。MicrosoftのAzure ReposレビューのドキュメントとBoardsのコーディング連携要件は異なる連携を説明しています。「Copilotが使える」「使えない」という一括りの説明では、購入判断に必要な精度を満たしません。

GitHubからの移行： 元のGit URLと必要な認証情報を使い、リポジトリのインポート手順を実行します。MicrosoftのGitインポートガイドは、新規または空の移行先リポジトリへの取り込みを説明しています。Large File Storage（LFS）は、大きなバイナリを通常のGitオブジェクトの外に保存します。ポインターはリポジトリと一緒に移っても、実ファイルは別途転送が必要な場合があります。GitHubのIssueとプルリクエスト履歴は別途計画してください。

試験移行には、ソースだけのライブラリよりも、ビルド成果物とデプロイ承認を持つ既存サービスが適しています。リリース責任者に、Boardsの作業項目からデプロイ完了まで変更をたどってもらいます。現在より流れが明確になれば、スイートが役立っていると判断できます。開発者が複数のトラッカーを手作業で更新する必要が出たなら、移行によって調整の問題が増えています。

Codeberg：フリーソフトウェア向きで、非公開の製品開発企業には不向き

Codebergは、Forgejoを基盤とする非営利のホスティング型開発サービスです。コード管理と共同開発を扱うこの種の基盤はforgeとも呼ばれます。フリーソフトウェアとしての運営方針を重視する公開ライブラリやコミュニティプロジェクトに有力な選択肢です。ただし、利用資格が制約になります。非公開のSaaSコードを置く汎用の商用ホスティングではありません。サービスの使命やリソース利用規則は、移行後に確認する細則ではなく、製品選定の条件です。

向いているプロジェクト： 運営団体の使命に合うフリー・オープンソースプロジェクト。
特徴： コミュニティを重視したホスティングと、AI学習に対する明確な姿勢。
料金： Codeberg FAQによると、対象の利用は$0で、任意の寄付と会費で支えられています。
無料トライアル： 条件を満たすホスティングは継続利用できます。商用の試用から上位プランへ移る仕組みではありません。

CI/CD・Issue・レビュー： Issueとプルリクエストを利用できます。Woodpecker CIは利用申請と手動承認が必要です。Forgejo Actionsではセルフホストランナーを使え、限定的なホステッドサービスもオープンアルファとして提供されています。CIのドキュメントにはこれらの条件が明記されています。「CI対応」は、新規プロジェクトすべてにマネージドランナー群が即座に割り当てられるという意味ではありません。

AIコーディングアシスタント： 確認した製品ページでは、提供元独自のコーディングアシスタントは案内されていません。Codebergは、ホストするプロジェクトやユーザーのデータを生成AIの学習に使わず、LLM生成物への依存が大きいプロジェクトを制限するとしています。公開されたポリシーの説明では、活動を続ける既存コミュニティや時折の生成物の投稿と、エージェントに大きく依存して作成・保守されるプロジェクトを区別しています。過去にAIを使った投稿があれば自動的に対象外になる、と読み替えないでください。

GitHubからの移行： プラスメニューからNew Migration、GitHubを選び、必要なアクセストークンを入力して移すメタデータを指定します。Codebergの移行ガイドは、Issue、ラベル、リリース、マイルストーンなど、対応するメタデータを説明しています。汎用のGitソースを選ぶと、追加メタデータを伴わないリポジトリ内容の転送になります。移行を検収したらトークンを失効させます。

ボランティアが保守する公開の依存ライブラリでは、新しい貢献者の最初の体験もインポートと同じくらい重要です。新しい投稿手順を公開し、レビューの場所を説明して、正式なプロジェクトの所在を明確にします。リポジトリだけを移してコミュニティの習慣を移さなければ、保守担当者は両方を監視することになります。

Codebergは大半のサービスをベルリンの自社ハードウェアで運用していますが、FAQには一部の処理で別の場所や提供元を使うと記載されています。これは有用なインフラ情報であり、データの全コピーをドイツ国内に保管する契約上の約束ではありません。厳格な所在地要件がある非公開の商用事業なら、寄付による例外を期待するより、自社で管理するホスティング環境を評価してください。

SourceHut：メール中心の開発とAIポリシーを理解して選ぶ

SourceHutは、Git、メーリングリスト、チケット管理、ビルドを中心にしたオープンソースの開発スイートです。GitHubのプルリクエスト体験を再現するより、Webツールを補助に使いながらメールでパッチをレビューしたい保守担当者に向いています。すでにメーリングリストで投稿を議論するプロジェクトには、検討する明確な理由があります。制約は、ワークフローの変更、パブリックアルファという提供段階、そして現在広く行われるコーディング手法の多くを認めないホスティング側のAIポリシーです。

向いているプロジェクト： メールによるパッチレビューを積極的に選ぶプロジェクト。
特徴： メーリングリストを軸にした共同開発。
料金： ホスティング契約は適用される税を除き月額$4から。有料の各段階で利用できるサービスは同じです。SourceHut料金ページに記載されています。
無料トライアル： アルファ期間中は多くのサービスで支払いが任意ですが、ビルドは有料です。貢献者は参加するだけなら支払う必要はありません。

CI/CD・Issue・レビュー： CIのbuilds.sr.ht、チケットのtodo.sr.ht、Webツールを備えたメーリングリスト上のパッチレビューを含みます。パッチはレビュー用に送るコード変更案で、保守担当者が議論し、承認した修正版を適用します。デリバリー自動化はプロジェクトごとに設定が必要です。契約すれば完成したリリースシステムが手に入るわけではありません。

AIコーディングアシスタント： SourceHutはAI機能を提供しないと明言しています。AIポリシーの変更はさらに踏み込み、2026年9月10日から新規プロジェクトについて、生成AIが執筆・支援したオリジナルコンテンツと、生成AIを実現・支援するソフトウェアをホステッドサービス上で禁止しています。適用には公表された解釈と例外があります。説明では、非公開の分析やレビューに使った後、自分でオリジナルの内容を書くことは認めています。アシスタントが書いたコードを日常的に投稿するチームには、このホステッドサービスは適しません。

GitHubからの移行： Gitサービスのマニュアルには、外部のソースをクローンしてgit.sr.htへ追加する方法が記載されています。これはGitの転送経路です。GitHubのプルリクエストの議論が同等のメーリングリストスレッドになったり、Issueが自動的にチケットへ対応付けられたりする証拠ではありません。別々に棚卸しし、アーカイブとして読める状態を残す必要がある履歴を決めます。

企業のプロジェクトを切り替える前に、初参加の人に投稿手順を試してもらってください。パッチを送り、指摘に応答し、採用された修正版を見つけられるでしょうか。経験豊富な保守担当者にはすっきりした手順でも、ほかの参加者には習得の手間がかかる場合があります。その価値があるとしても、意識して選ぶべき運用判断です。

ソフトウェアはセルフホストも可能です。SourceHutのホステッドサービスの利用資格とは区別してください。自社管理のインフラで動かす場合は、導入形態と責任の分担が異なります。

AWS CodeCommit：新規利用を再開したものの、置き換え範囲は限定的

AWS CodeCommitは、リポジトリへのアクセスをAWSの運用体系内に収めたい組織向けの、マネージドな非公開Gitリポジトリサービスです。AWSのID権限とネットワーク境界が中心的な要件なら候補に入ります。AWSの受付再開の発表には、新規顧客を再び受け付けると明記されています。一部の古いAWSページには受付停止のバナーが残っていますが、再開発表と現行ドキュメントの履歴が、その停止告知を更新しています。

向いている組織： リポジトリの境界に具体的な要件がある、AWS中心の組織。
特徴： AWSのID・インフラサービスと統合したリポジトリアクセス。
料金： 無料枠があり、有料利用は$1/アクティブユーザー/月に該当する超過料金が加わります。CodeCommit料金FAQに記載されています。
無料トライアル： 全機能を期間限定で試す形式ではなく、継続的な無料枠です。

CI/CD・Issue・レビュー： CodeCommitはプルリクエストと共同レビューに対応します。ビルドとデリバリーの自動化には、AWS CodeBuildやAWS CodePipelineなど別のサービスを使います。Issueトラッカーも別途用意します。複数サービスを組み合わせる構成なので、リポジトリ契約を開発全体の包括契約とみなさず、組み上がるワークフローと請求額を比較してください。

AIコーディングアシスタント： AWSはコーディング支援としてAmazon Q Developerを提供しています。これは別の製品です。CodeCommitを購入すれば、すべてのリポジトリやレビューに標準アシスタントが自動で付くという意味ではありません。リポジトリの選定とアシスタントの利用権は分けて考えます。

GitHubからの移行： AWSのGitリポジトリ移行ガイドでは、既存のGitリポジトリを取得し、CodeCommitの移行先を作成してコードを転送します。GitHub Issues、プルリクエストの会話、Actionsワークフローまで取り込む手順ではありません。それぞれ別の仕組みとして置き換えるか保存します。

適切な試験移行では、想定するAWS構成内でアクセスとデリバリーを確認します。予定している開発者IDでリポジトリを取得できるか。ビルド用IDは必要なソースだけにアクセスできるか。意図した権限でリリースを進められるか。こうした問いが、より統合的な画面を持つ別の開発基盤があってもCodeCommitを選ぶ理由になります。

評価： AWS連携が移行理由なら候補に含めます。単にGitHubに近い代替先を探す創業者なら、まずGitLabかGiteaを評価してください。

セルフホストを選ぶなら：Gitea、GitLabと運用の責任

インフラを選び、アプリケーションを管理し、復旧を自社で制御する必要があるなら、セルフホストが最も適しています。同時に、障害への責任も引き受けます。判断のポイントは導入が簡単そうかどうかではなく、ディスク、データベース、アップグレードの障害時に復旧できる担当者がいるかです。

Gitea：セルフホストで最初に検討したい候補

Giteaは、リポジトリ、Issue、プルリクエスト、自動化を備えるオープンソースの開発基盤です。大規模なスイートを最初から採用せず、自社のコード基盤を運用したい小規模な開発組織にとって、評価の出発点に適しています。社内ツール開発チームは、稼働場所を選びながら、リポジトリのそばにレビューとタスクをまとめられます。制約は運用責任です。無料ライセンスにバックアップ、監視、ランナーの分離、復旧担当者まで付いてくるわけではありません。

向いているチーム： 開発基盤を自社管理したく、その運用を担えるチーム。
特徴： オープンソース製品にリポジトリ、Issue、プルリクエスト、Actionsを含みます。
料金： Gitea料金ページによると、Open SourceはMITライセンスで$0。ホスティングと管理の費用は別途必要です。
無料トライアル： オープンソース版は継続利用できます。提供元は別途商用版のトライアルも用意しています。

CI/CD・Issue・レビュー： Issueとプルリクエストを備え、CI/CDにはGitea Actionsを使います。Actionsのドキュメントでは、GitHub Actionsとおおむね互換性があり、別のランナープログラムを使うと説明されています。「おおむね」が重要です。慣れたワークフローファイルを使えることは移行上の利点ですが、すべてのアクション、権限の前提、連携が同じように動く証拠にはなりません。

AIコーディングアシスタント： 確認した公式の製品・料金ページでは、提供元独自のコーディングアシスタントは案内されていません。これはAI禁止という意味ではありません。別のエディターアシスタントやレビューボットを使う場合は、リポジトリアクセス、データの扱い、連携対応を個別に評価します。

GitHubからの移行： Giteaの移行ドキュメントは、必要なアカウント情報を入力した場合にIssueやプルリクエストなども扱える、組み込みのGitHub移行フォームを説明しています。代表的なプロジェクトでインポートし、議論とユーザーの対応付けを確認してください。Actionsの設定とシークレットは別の受け入れテストとして扱います。

たとえば、非公開の社内アプリケーションで、テストのワークフローは単純でも、リリースジョブが特定のホステッドIDプロバイダーを前提にしている場合があります。テストジョブを再利用できても、リリースジョブを検証したことにはなりません。移行完了を宣言する前に、試験移行でデプロイ先まで到達し、復旧できることを示してください。

GiteaにはマネージドのCloudとEnterpriseもあり、セルフホスト専用の製品ではありません。ここで推奨しているのは、自社で管理するOpen Source版です。組織のIDシステムとログインをつなぐSAMLシングルサインオンなどの企業向け制御は、無料版にあると決めつけず、エディションごとに確認します。

GiteaとGitLab：必要な運用範囲で選ぶ

機能を絞った開発基盤で業務を賄え、自社運用できるならGiteaを選びます。幅広いGitLabワークフローこそが移行理由で、その管理負担を引き受けられるならGitLab Self-Managedを選びます。ホスティング料金を払わずソフトウェアをダウンロードできるという理由だけで選ぶべきではありません。運用コストには、失敗したバックアップを調べる担当者の工数や、停止中に開発者が失う時間も含まれます。

Codebergはマネージドサービス、Forgejoはそこで使われているソフトウェアです。Forgejoのセルフホストは、Codebergアカウントの取得とは別の選択肢です。SourceHutのソフトウェアも自社インフラへ導入できます。オープンソースのホステッドサービスと、提供元が自社専用環境まで運用してくれるという約束を混同しないことが重要です。

Bitbucketの自社運用については、別途利用資格の確認が必要です。AtlassianのHybrid Licenseページによると、対象は既存のBitbucketまたはBambooのServer/Data Center顧客です。GitHubから初めて移る企業が、新規にセルフホストを始める経路ではありません。同時に、Data Center全般の提供終了発表を、Bitbucketの自社運用製品も一律に消えるという意味で解釈すべきではありません。

チームの要件に合う移行先はどれか

コストが主な問題なら、移行前に業務全体の構成で比較します。 小規模企業では、まずホスティング型の無料枠を確認します。ビルド能力、Issue管理、必要なID制御、アシスタントの利用権まで含めてください。リリース工程を再現する作業を織り込んでも節約や制御の利点が残る場合に、切り替えます。

インフラの制御が必須なら、GiteaとGitLab Self-Managedから検討します。 幅広いプラットフォームによって複数の別ツールを十分に減らせ、運用範囲の広さに見合うならGitLab寄りです。リポジトリ、Issue、レビュー、適切なCI構成で仕事を賄えるならGitea寄りです。

既存環境との統合を重視するなら、現在の業務調整の場所に合わせます。 Jira中心の計画にはBitbucket、BoardsとPipelinesのワークフローにはAzure DevOps、AWS内での具体的なリポジトリ要件にはCodeCommitが合います。請求を避けるためだけに別の環境を採用すると、減る以上の管理作業が生まれる場合があります。

公開のコミュニティ主導プロジェクトなら、貢献者との相性を決め手にします。 慣れた形の開発基盤を求めるフリーソフトウェアプロジェクトには、Codebergが分かりやすい選択肢です。SourceHutは、パッチレビューのワークフローを積極的に選び、AI規則を守れる保守担当者向けです。「無料」という見出しだけで選ぶべきではありません。

GitHub Actionsの代替：リリースジョブから検証する

GitLab CI/CD、Bitbucket Pipelines、Azure Pipelines、Gitea Actions、Codebergの各CI、SourceHutのビルドでは、運用形態が異なります。CodeCommitは別のAWSデリバリー基盤と接続します。したがって、移行の単位は設定ファイルではなく、実際に動くパイプラインです。

チェックアウト、キャッシュ、パッケージへのアクセス、デプロイ認証情報、承認ゲート、通知など、現在のホストに依存する手順を棚卸しします。最も制約の多いリリースジョブを早い段階でテストしてください。移行先で安全に実行できなければ、リポジトリのインポートに成功しても障害は解消していません。Giteaの互換性で書き換えを減らせても、このテストは必要です。

GitHub Copilotの代替：アシスタントとホスティングを分けて考える

Gitのリモートを変えても、開発者がどのアシスタントを使えるか、そのアシスタントがコンテキストをどこへ送るかは決まりません。GitLabにはDuo、Atlassianには移行中のRovo開発ツールがあり、MicrosoftのAzure Reposレビュー連携はGitHub Copilotを使います。AWSはAmazon Q Developerを別途提供しています。確認したGiteaのページには標準の同等機能は案内されていません。CodebergとSourceHutは、アシスタントの選択以上に注意が必要なポリシーを設けています。

要件は具体的に記述します。送信コードを学習に使わないこと、外部処理を行わないこと、生成された投稿を受け付けないこと、特定の供給元に依存しないことは、それぞれ異なるポリシーです。同じ基盤でも、ある条件は満たし、別の条件は満たさない場合があります。GitHub Copilot料金ガイドを使い、アシスタントの費用はリポジトリのホスティングと分けて評価してください。

データ所在地：コードの行き先をリポジトリの外まで追う

リポジトリの場所は、データ所在地の判断の一部にすぎません。ビルドランナーがソースコードを受け取り、ログに機密情報が含まれ、Gitオブジェクトの保存先とは無関係にAIサービスへコード断片が送られることがあります。顧客要件に対応する開発責任者にとって有用なのは、これらの転送経路と、それを対象とする契約を示した図です。

MicrosoftのAzure DevOpsデータ所在地のドキュメントは、ヨーロッパやカナダなど選択できる地域と、顧客データの所在地に関する限定的な例外を説明しています。Codebergもインフラの場所を説明していますが、非公開の商用ホスティング契約の代わりにはなりません。セルフホストでは導入場所を選べますが、外部のアシスタントやビルドサービスを自動的に制約できるわけではありません。

リポジトリ、データベース、バックアップ、ログの所在、サポートがアクセスする場所、コードを受け取る再委託先を確認します。CIとAIにも同じ確認を行ってください。「コードをこの環境の外へ出さない」という要件なら、リージョンを選ぶだけで済ませず、関係する接続部分で制御します。

GitHubを離れると失うもの

GitHubを離れると、ネットワークの利便性の一部を失います。潜在的な貢献者はすでにアカウントを持ち、レビュー画面を知り、慣れたプロフィールやリポジトリを通じてプロジェクトを見つけられます。また、Actionsのマーケットプレイスの部品が、移行先でも同じ権限と連携で変更なく動くという前提は置けなくなります。移行先に活発なコミュニティがあっても、オープンソースのプロジェクトを見つけてもらうために、自分たちが担う役割は増えます。こうしたコストは、非公開の社内アプリケーションより、貢献者を募る公開の開発者向けツールに強く影響します。公開ミラーで見つけやすさを保てる場合もありますが、投稿先の案内と正式な開発拠点を明確にする必要があります。曖昧なままでは、保守担当者が確認すべきIssueとレビューが重複します。

比較対象の選定・確認方法

機能数による順位より、意思決定に必要な根拠を重視しました。各候補について、現在の利用可否、ホスティング形態、CI/CD、Issueとレビュー、提供元が示すAI機能、GitHubからの移行経路、公開されている開始料金を確認しています。GitLab、Bitbucket、Azure DevOps、Giteaには登録、購入、試用、ダウンロードの経路があり、CodebergとSourceHutには登録経路がありました。AWSは受付再開を明示しています。

比較内容は、2026年11月5日に一次情報の製品・料金・ドキュメントページで確認しました。性能測定、サポート応答テスト、試験移行は行っていません。推奨は、こうした根拠に基づくワークフローとの適合性の判断です。好意的な評価が、プロジェクトの利用資格や、実際のリリース工程をテストする必要性に優先するわけではありません。

避けるべき選び方

非公開の独自製品を開発する企業は、Codebergを避けます。 その使命はフリーソフトウェアで選ぶ理由であり、一般的な非公開の商用ホスティングで除外する理由でもあります。任意の寄付で利用規則を変えることはできません。

通常の投稿手順が生成コードに依存する場合や、生成AIを実現・支援する製品では、ホステッドのSourceHutを避けます。 現行ポリシーはアシスタントの任意設定ではなく、適合性に関わる制約です。貢献者がGitHubに近いレビュー体験を必要とし、ワークフローの習得に予算を割いていない場合にも適しません。

Bitbucket Hybridを、新規のセルフホスト購入経路とみなさないでください。 利用資格のページには既存顧客向けと明記されています。本記事のCloud版を評価するか、自社で導入できるソフトウェアを選びます。

CodeCommitを、開発全体を置き換える標準候補として選ぶことは避けます。 AWSのリポジトリサービスとして適切な場合はありますが、周辺のIssue管理とデリバリーワークフローは設計が必要です。過去の新規受付停止は、現在それを除外する理由にはなりません。

クローン成功だけを根拠に移行を完了しないでください。 レビュアーがコードの背景にある判断を見つけられなかったり、移行先からリリースできなかったりするなら、基盤の移行は未完了です。

GitHub移行の受け入れチェックリスト

リポジトリ転送の成功で壊れたワークフローを見落とさないよう、層を分けて検収します。以下は評価の枠組みであり、すべてのインポーターが各層を移せるという意味ではありません。

1. 1

   リポジトリの完全性を確認する

   必要なブランチとタグを比較し、代表的なコミットを調べ、大きなファイルを取得できることを確かめます。独立したバックアップを保持し、検収が完了するまで移行元を残します。

2. 2

   過去の判断を引き続き読めることを確認する

   Issue、完了済みレビュー、添付ファイル、リリースノートを調べます。欠けた履歴をインポート、アーカイブ、リンクのどれで残すか決めます。参照切れを解消する担当者を置いてください。

3. 3

   移行先からリリースできることを確認する

   認証情報、成果物へのアクセス、デプロイ承認を明示的に設定します。安全な対象へリリース工程を実行し、復旧も予行します。検収後は一時的なインポート認証情報を失効させます。

4. 4

   アクセス権と切り替え責任者を確認する

   開発者、レビュアー、ビルド用ID、退職者のアクセスを確認します。最終同期を予定し、新しい投稿先を周知して、移行をロールバックする権限を持つ担当者を指名します。

次の作業で目指すべきは、候補一覧を長くすることより、試験移行の結果を出すことです。必須条件を満たす移行先を選び、代表的なリポジトリを移して、リリース責任者にワークフローを検収してもらいます。その根拠がそろってから対象を広げます。

よくある質問

GitHubの代わりに何を使うのがおすすめですか？

リポジトリ、Issue、レビュー、CI/CDをまとめたいなら、GitLabが幅広い用途の最有力候補です。機能を絞った開発基盤で足り、自社運用できるなら、セルフホストではまずGiteaを評価します。Jiraへの依存、コミュニティの方針、AWS内の境界要件によって推奨は変わります。

TFSとGitはどちらがよいですか？

種類の異なるツールです。Azure DevOps Serverの前身であるTeam Foundation Serverは開発プラットフォームで、Gitは分散型のバージョン管理システムです。GitとTeam Foundation Version Controlを比較したい場合は、MicrosoftのTFVC概要が集中型の選択肢を説明しています。リポジトリのホスティング先を変えるためにGitをやめる必要はありません。

NASAはGitを使っていますか？

はい。NASAはオープンソース開発の概要で、ソフトウェアの公開にGitHubを使うと説明しています。Gitリポジトリの実利用を示すものであり、NASAのすべてのシステムに共通する規則を意味するわけではありません。

GitHub自体はオープンソースですか？

GitHubのホステッドプラットフォームは独自の非公開ソフトウェアです。基盤となるバージョン管理ツールのGitはオープンソースで、GitHubには多数のオープンソースプロジェクトが置かれています。オープンソースのプロジェクトを選ぶことと、オープンソースのホスティング基盤を選ぶことは別です。

GitHubのボイコットにはどのような理由がありますか？

非公開のホスティング基盤、供給元への依存、AI利用への異議など、理由はさまざまです。CodebergとSourceHutは、前述のようにAIとソフトウェアの運営方針について明確な立場を公開しています。組織としては、どの代替先も同じ方針だと思い込まず、懸念を検証可能な要件へ置き換えてください。

初心者向けにいうと、GitHubとは何ですか？

GitHubはコードを共有する作業場所です。変更履歴を保存し、更新の提案とレビューを可能にして、Issue管理や自動化を支えます。代替先によって、この作業場所のどこまでを提供するか、誰が運用するかが異なります。

GitHubの利用にはリスクがありますか？

考えるべきなのは、アカウントへのアクセス、認証情報の漏えい、リポジトリ権限、外部の自動化、データ転送のうち、どのリスクを制御したいかです。提供元を変えても、その責任はなくなりません。セルフホストでは、パッチ適用、バックアップ、復旧も自社の責任になります。

GitHubは100% Microsoftの所有ですか？

はい。Microsoftは2018年にGitHubの買収を完了しました。買収完了の発表に記録されています。Azure DevOpsへ移るとプラットフォームは変わりますが、供給元は引き続きMicrosoftです。

米国政府はGitHubを使っていますか？

はい。NASAが公表している利用は、文書で確認できる連邦機関の事例です。ただし、GitHubやほかの代替先が、政府のすべてのプロジェクトや情報区分で承認されていることを示すものではありません。

開発環境を変更する前に、AI Business Workflow Audit Checklistを入手し、新しいワークフローで維持すべきものを整理してください。