GitHub（ギットハブ）は、Gitを使ったソースコードの共有・共同開発のためのプラットフォームである。インターネット上にソースコードを保管（ホスティング）し、複数の開発者が同じコードに対して変更を提案し合い、レビューを経てまとめていく一連の作業を支える。世界中の多くの企業や個人開発者、オープンソースプロジェクトの拠点として広く使われている。

この記事の要点
GitHub は、バージョン管理ツール Git のリポジトリをインターネット上で公開・共有できるホスティングサービスである。 Git（手元でバージョン管理を行うツール）と GitHub（それを置く場所・共同作業の場）は別物であり、両者を混同しないことが理解の出発点になる。 中心となる機能は、コードを保管するリポジトリ、変更を提案するPull Request、課題管理のIssue、自動化のActions（CI/CD）など。 基本的な流れは「リポジトリ作成 → clone → 編集 → commit → push → Pull Request」。 リポジトリは公開（Public）と非公開（Private）を選べる。公開リポジトリへの機密情報の混入には特に注意が必要。

 

GitHubとは

GitHub は、ソースコードをインターネット上のリポジトリ（コードの保管庫）に置き、変更履歴を残しながら複数人で開発を進めるためのWebサービスである。単なるファイル置き場ではなく、コードの変更を「誰が・いつ・なぜ」行ったかを記録し、その変更を他のメンバーが確認・議論・承認してから本流に取り込む、という共同開発の仕組み全体を提供する点が特徴である。

利用形態は大きく分けて2つある。1つはブラウザ上でリポジトリの内容を閲覧したり、Pull RequestやIssueを操作したりするWeb画面。もう1つは、手元のパソコン（ローカル環境）にコードを取得して編集し、その結果を送り返す、コマンドや専用アプリを使った操作である。日々の開発ではこの両者を行き来しながら作業を進めるのが一般的である。

オープンソースソフトウェアの公開先としても広く使われており、世界中のライブラリやツールのソースコードが公開されている。利用者はそれらを閲覧・取得して自分のプロジェクトに利用したり、不具合の報告や改善の提案を行ったりできる。こうした「誰でも参加できる開発の場」としての性格が、GitHubが単なるコード置き場以上のものとして広く普及した理由の1つである。

個人開発から大規模な企業開発まで、扱える範囲が広いことも特徴である。1人で書いたコードを記録・バックアップする用途にも使えるし、数十人・数百人が同時に関わる開発で変更を整理し、品質を保ちながら統合していく用途にも対応できる。最初は小さく使い始め、必要に応じて機能を増やしていける点が、はじめて触れる人にも取り組みやすいところである。

GitとGitHubの関係

GitHubを理解するうえで最初に押さえておきたいのが、Git と GitHub の違いである。名前が似ているため混同されやすいが、役割はまったく異なる。

• Git は、ファイルの変更履歴を管理するバージョン管理ツール（ソフトウェア）である。手元のパソコンにインストールして使い、インターネットに接続していなくても変更の記録（commit）を残せる。
• GitHub は、そのGitのリポジトリをインターネット上に置いて共有するためのホスティングサービスである。Gitの機能に加えて、Web画面での閲覧、Pull Requestによるレビュー、Issueによる課題管理など、共同開発を助ける機能を上乗せして提供している。

たとえるなら、Gitは「文書の変更履歴を管理する仕組み」、GitHubは「その文書を皆で共有し、コメントを付け合いながら編集していく共有スペース」に近い。Git自体は単独で使えるが、複数人での開発や公開を行う際にGitHubのようなホスティングサービスを併用することが多い、という関係になる。

なお、Gitのリポジトリを共有する仕組みはGitHub以外にも存在する。GitHubはその中で代表的なサービスの1つという位置づけである。

主な機能

GitHubが提供する代表的な機能を、用途とともに整理する。プロジェクトの規模や目的に応じて、必要なものから使っていくとよい。

機能	分類	主な用途
リポジトリ（Repository）	コード管理	ソースコードや関連ファイル、変更履歴を保管する基本単位。プロジェクトごとに作成する。
Pull Request	変更提案・レビュー	ある変更を本流に取り込むよう提案し、内容を他のメンバーがレビュー・議論してから取り込む仕組み。
Issue	課題管理	不具合報告・機能要望・タスクなどを記録し、担当者やラベルを付けて管理する。
Actions	自動化（CI/CD）	変更があった際にテストやビルド、デプロイなどの処理を自動で実行するワークフローを組める。
Pages	Webサイト公開	リポジトリの内容を静的なWebサイトとして公開できる。ドキュメントや個人サイト等に利用される。
Projects	進捗管理	IssueやPull Requestをボードや表の形で並べ、作業の進捗を可視化・管理する。
Wiki / README	ドキュメント	プロジェクトの説明や使い方をまとめる。READMEはリポジトリのトップに表示される。
Fork	複製・派生	他者のリポジトリを自分のアカウントに複製し、自由に変更を加える。改善提案の起点にもなる。

 

このほか、変更履歴やコードの差分を確認する機能、コードの脆弱性やシークレット混入を検知するセキュリティ関連の機能、AIによるコーディング支援機能（GitHub Copilot）なども提供されている。提供される機能やその範囲は時期やプランによって変わるため、最新の内容は公式サイトで確認してほしい。

使い方の基本的な流れ

個人が手元のパソコンでコードを編集し、GitHub上のリポジトリに反映するまでの典型的な流れを示す。ここではコマンド（CLI）を使う例を取り上げるが、専用のデスクトップアプリやエディタの統合機能でも同様の操作が行える。

1. リポジトリを作成する：GitHub上で新しいリポジトリを作成する（または既存のリポジトリを利用する）。
2. clone（クローン）する：そのリポジトリを手元のパソコンに複製する。
3. 編集する：手元でファイルを追加・修正する。
4. commit（コミット）する：変更内容を「ひとまとまりの記録」としてローカルに保存する。
5. push（プッシュ）する：ローカルの変更をGitHub上のリポジトリへ送る。
6. Pull Requestを作成する：変更を本流（主要なブランチ）へ取り込むよう提案し、レビューを受ける。

この流れの中でよく登場するのがブランチ（branch）という考え方である。ブランチは作業の「枝分かれ」を表すもので、本流（多くは main と呼ばれるブランチ）とは別に作業用のブランチを切り、そこで変更を進めてから、Pull Requestを通じて本流へ合流させる。こうすることで、開発中の不安定な変更が本流に直接混ざるのを防ぎ、複数の作業を並行して進めやすくなる。

コマンドの一例を以下に示す。リポジトリのURL部分は利用するリポジトリに合わせて読み替える。

# リポジトリを手元に複製する $ git clone https://github.com/<ユーザー名>/<リポジトリ名>.git # 変更したファイルを記録対象に加える $ git add . # 変更をローカルに記録する $ git commit -m "変更内容の説明" # 変更をGitHubへ送る $ git push

 

push まで済むとGitHub上に変更が反映されるので、続いてWeb画面からPull Requestを作成し、メンバーのレビューを経て本流へ取り込む、という流れになる。1人での開発であればPull Requestを省略して直接本流へ反映することもある。

公開リポジトリと非公開リポジトリ

リポジトリには、誰でも閲覧できる公開（Public）と、許可した人だけが閲覧できる非公開（Private）の2種類がある。用途に応じて選ぶ。

• 公開（Public）：インターネット上の誰でもコードを閲覧できる。オープンソースプロジェクトや、広く共有したいサンプル・ライブラリなどに向く。
• 非公開（Private）：指定したメンバーだけが閲覧・編集できる。業務で扱うコードや、外部に見せたくないプロジェクトに向く。

なお、リポジトリは個人のアカウントだけでなく、Organization（組織）という単位の下にまとめて管理することもできる。会社やチームでの利用ではOrganizationを作り、その中で複数のリポジトリやメンバーの権限を一元的に管理するのが一般的である。誰がどのリポジトリを閲覧・編集できるかを役割ごとに設定できるため、関わる人数が増えても安全に運用しやすい。

非公開リポジトリの作成可否や利用可能な人数、各種機能の上限などはプランによって異なる。無料・有料それぞれで提供される範囲は変動するため、最新の内容は公式サイトの案内を確認してほしい。

他のサービスとの位置づけ

GitのリポジトリをホスティングするサービスはGitHubだけではない。代表的なものに GitLab や Bitbucket がある。いずれもGitを基盤とし、リポジトリ管理・変更提案・課題管理・CI/CDといった機能を備えている点は共通しているが、料金体系・自前のサーバーへ設置できるか（セルフホスト）・連携できる外部ツールなどに違いがある。

どのサービスが適しているかは、チームの規模・運用方針・既存ツールとの相性などによって変わる。GitHubはオープンソースコミュニティでの利用が特に広く、公開プロジェクトの拠点として選ばれることが多い、というのが2026年時点での一般的な位置づけである。具体的な機能比較や料金は各サービスの公式情報で確認することを勧める。

注意点・落とし穴

つまずきやすいポイント

公開リポジトリへの機密情報の混入：APIキー・パスワード・接続情報などをコードや設定ファイルに書いたまま公開リポジトリへ push すると、第三者に閲覧されるおそれがある。一度公開した情報は履歴にも残るため、混入させない運用（公開対象から除外する、設定値を直接書かない等）が重要。 大容量ファイルの扱い：動画や巨大なデータなどをそのまま管理すると、リポジトリが重くなったり容量の制限に触れたりすることがある。大きなファイルには専用の仕組み（大容量ファイル向けの拡張など）の利用を検討する。 認証はパスワードではない：コマンドラインからのHTTPS接続では、アカウントのログインパスワードはGit操作に使えない。アクセストークンやSSH鍵といった認証方式を用いる必要がある。「パスワードが通らない」というつまずきの多くはこれが原因である。 GitとGitHubの混同：手元での記録（commit）はGitの操作であり、GitHubへ反映するには別途 push が必要。commit しただけではGitHub上に反映されない点に注意する。

 

よくある質問（FAQ）

Q. GitとGitHubは何が違うのですか？
A. Gitは手元のパソコンで変更履歴を管理する「ツール（ソフトウェア）」、GitHubはそのGitのリポジトリをインターネット上で共有・共同編集するための「サービス」です。Gitは単独でも使えますが、複数人での開発や公開を行う際にGitHubのようなホスティングサービスを併用します。

Q. GitHubは無料で使えますか？
A. 無料で利用できる範囲があり、公開・非公開いずれのリポジトリも作成できます。ただし利用人数や一部機能の上限などはプランによって異なります。提供内容は変動するため、最新の料金や条件は公式サイトで確認してください。

Q. プログラミングのコード以外も置けますか？
A. テキストや設定ファイル、ドキュメントなど、ファイル全般を管理できます。ただし用途はソースコードを中心とした開発・共同作業を想定しており、巨大なバイナリファイルの大量保管などには向きません。

 

※本記事は2026年時点の一般的な情報に基づく。提供機能・プラン・料金などは変更されることがあるため、利用前に公式サイトの最新情報を確認してほしい。