システム開発において「GitHubを使わない」という選択肢もありうる

もちろん使えるなら使うべきですが、セキュリティ的に使えない現場もありますよ～とか、そもそもGit使ってませんよ～みたいな現場もあるという噂はを耳にしたので記事化してみました。

そもそも「Git」と「GitHub」は別物である
1. Gitとは
2. GitHubとは
GitHubを使用するリスク
ならどうすればいいのか？
1. 手順①：サーバー側に「ベアリポジトリ」を作成する
2. 手順②：ローカルPCからリモートとして登録する
その他の選択肢（オンプレミス型Gitサーバー）
まとめ

そもそも「Git」と「GitHub」は別物である

初心者の方や、学習段階からGitHubを利用している方の中には、この2つを混同しているケースが見受けられます。

Gitとは

ツールそのものです。分散型バージョン管理システムであり、あなたのPC上で動作し、ファイルの変更履歴を記録します。
インターネット環境がなくても、ローカルPCだけで機能します。

Git - Wikipedia

GitHubとは

Webサービスです。Gitのリポジトリ（保存場所）をオンライン上で預かり、複数人での共有やコラボレーション（プルリクエスト、Issue管理など）をしやすくするプラットフォームです。
あくまで「Gitのホスティングサービスのひとつ」に過ぎません。

GitHub - Wikipedia

つまり、「Gitを使うために、必ずしもGitHubを使う必要はない」 のです。

GitHubを使用するリスク

世界的人気ツールであるGitHubですが、利用にはいくつかのリスクや考慮すべき点が存在します。

セキュリティと情報漏洩のリスク

最も懸念されるのは、設定ミスによる情報漏洩です。

「Private（非公開）」にするはずのリポジトリを誤って「Public（公開）」に設定してしまい、社外秘のコードやAPIキーが世界中に公開されてしまう事故は後を絶ちません。

GitHub上に三井住友銀の一部コードが流出、「事実だがセキュリティーに影響せず」

三井住友銀行（SMBC）が行内で使っている業務システムのソースコードの一部が流出していたことが明らかになった。三井住友銀行が1月29日に事実関係を調査し、行内システムのソースコードの一部と一致したことを確認した。

また、ソースコードという重要資産を「他社（Microsoft傘下のGitHub社）のサーバー」に預けること自体が、極めて高いセキュリティレベルを求めるプロジェクトでは許容されない場合があります。

サービス依存（ベンダーロックイン）

GitHubは単なるコード置き場を超え、プロジェクト管理、CI/CD、セキュリティチェックなど多機能化しています。

便利である反面、開発フローがGitHubの機能に深く依存してしまうと、将来的に利用料が跳ね上がったり、規約変更があったりした際に、他のプラットフォームへ移行するのが極めて困難になります。

実際に最近一部サービスの料金体系変更のアナウンスがあっただけで開発者コミュニティが大騒ぎした事例もあります。

GitHub Actionsが価格プランの変更を発表、開発者から「値上げだ！」と猛反発を受けて大炎上して延期に

GitHubが、GitHubのイベントをトリガーにしてワークフローを自動実行できる「GitHub Actions」の価格モデルと製品モデルに関する大幅な変更を2025年12月16日に発表しました。この発表の核となるのは、GitHubがホスト...

サービスのダウンタイム

稀ではありますが、GitHub自体が障害でダウンすることがあります。

開発フローが完全にGitHubに依存している場合業務停止して思わぬ休日になってしまいます。

ならどうすればいいのか？

それは「社内LAN上のサーバーに共有リポジトリを作る」 ことです。

インターネット(WAN)に出る必要がないため、漏洩リスクなどを極小化できます。

手順①：サーバー側に「ベアリポジトリ」を作成する

サーバー上の任意の場所に、Git用のディレクトリを作成し、--bare オプションを付けて初期化します。
これが共有の中心（リモートリポジトリ）となります。

# サーバー側での操作（SSHなどでログインして実行）
$ mkdir -p /var/git/my-project.git
$ cd /var/git/my-project.git
$ git init --bare

状況に応じてディレクトリの所有権なども変更してください。

手順②：ローカルPCからリモートとして登録する

開発者のPCにある既存のプロジェクトから、先ほど作ったサーバー上の場所を「リモート（origin）」として登録します。通信にはSSHを使用します。

# 開発者のPC側での操作
$ cd my-project-folder
$ git init
$ git remote add origin ssh://ユーザー名@サーバーのIPアドレス/var/git/my-project.git
$ echo "test" > README.md
$ git add .
$ git commit -m "first commit"
$ git push -u origin master

これだけで、GitHubを使わずにチーム開発が可能な環境が整いました。

その他の選択肢（オンプレミス型Gitサーバー）

AIに聞いたら以下のような選択肢もあるようです。

「コマンドだけのリポジトリでは、プルリクエストやコードレビューの画面がなくて不便だ」という場合は、GitHubのようなWeb UIを持つシステムを自社サーバーに構築することも可能です。

GitLab (Self-Managed): 機能が非常に豊富で、GitHubに近い体験をオンプレミスで実現できます。ただし、サーバーのリソース（メモリ等）を多く消費します。

Gitea / Forgejo: 非常に軽量で、Raspberry Piのような小型サーバーでも快適に動作します。小〜中規模のチームであれば十分な機能を持っています。

これらを社内ネットワーク内に構築すれば、「GitHubのような利便性」と「完全なデータの自社管理」を両立させることができます。

まあ個人～小規模事業ならならありだと思いますが、企業ならその後や付属サービスを考慮してGitHub Enterpriseでオンプレミスサーバーを用意した方が便利な気がします。

まとめ

本記事は決して「GitHubを使うな」という主張ではありません。

しかし、以下のようなケースでは、今回紹介したような「GitHubを使わない選択」も検討の価値があります。

絶対に外部に漏れてはいけない極秘プロジェクト
インターネット接続が制限されている閉域網（イントラネット）での開発
外部サービスへの依存を極力減らしたい長期運用システム

要は適材適所です。