最低限おぼえる10の用語
このページで分かること
- リポジトリ・コミット・ブランチなど、頻出10語の意味が分かる
- 用語同士がどう繋がっているかを1枚の図として持てる
- 混同しやすい用語のペアを区別できる
このページの目次14 items
Git と GitHub が難しく感じる最大の理由は、知らない言葉が一度に押し寄せてくることです。ここで先に語彙を通しておけば、第2部以降の説明がすっと入ります。
いま完全に理解する必要はありません。「そういう名前のものがある」と分かれば十分です。実際の操作は第2部から行います。
左が手元のPC、右が GitHub です。間をつなぐ push・pull・clone 以外の用語は、どちらか片方の中だけで完結しています。以下の10項目を読みながら、この図のどこにあたるかを確かめてください（マージとコンフリクトは図に描いていません）。
1. リポジトリ（repository / repo）#
変更履歴を含めた、プロジェクト一式の入れ物。
日本語では「保管庫」。実体は1つのフォルダです。ふつうのフォルダとの違いは、中に .git という隠しフォルダがあり、そこに全履歴が入っている点だけです。
「リポジトリを作る」＝「このフォルダの変更履歴を取り始める」という意味になります。
2. コミット（commit）#
ある時点のファイルの状態を、メッセージを添えて記録すること。またはその記録そのもの。
バージョン管理の最小単位です。「セーブポイント」と説明されることが多いですが、より正確には変更の記録であり、それが数珠つなぎになって履歴を形成します。
コミットA ← コミットB ← コミットC ← コミットD
（古い） （新しい）各コミットは「1つ前のコミット」を指しており、この連なりが履歴の正体です。
コミットには次の情報が含まれます。
– 変更内容
– コミットメッセージ（なぜ変えたか）
– 作成者の名前とメールアドレス
– 日時
– 一意のID（a3f5b2c... のような40桁の文字列。ハッシュと呼ぶ）
3. ブランチ（branch）#
作業を分岐させるための「しおり」。
「枝」という訳語から、履歴が物理的に枝分かれするイメージを持ちがちですが、実体はもっと単純で、特定のコミットを指す名前付きのポインタです。
┌── コミットE ← feature ブランチ
│
A ← B ← C ← D ────────┘
↑
main ブランチ新しいブランチを作っても、ファイルがコピーされるわけではありません。だから Git のブランチは一瞬で作れて、気軽に捨てられます。この点は第4部の21で詳しく扱います。
代表的なブランチ名：
– main：本流。公開・リリースされる状態を保つ（以前は master が使われていた）
– feature/〇〇：新機能の開発用
– fix/〇〇：バグ修正用
4. マージ（merge）#
分岐した作業を1つに統合すること。
feature ブランチで作った変更を main に取り込む、というのが典型的な使い方です。Git は両者の変更を自動で合成しようとします。
同じ箇所を両方が別々に書き換えていた場合、自動で判断できずにコンフリクト（conflict、衝突）が起きます。このときは人間がどちらを採用するか決めます。怖い響きですが、単に「Gitが判断を人間に委ねている」だけです（第4部の24）。
5. リモート（remote）#
インターネット上に置かれたリポジトリのコピー。
対義語はローカル（local、自分のPC上のリポジトリ）です。GitHub 上のリポジトリは、ローカルから見ると「リモート」にあたります。
リモートには慣習的な名前が付きます。最初に登録したリモートは通常 origin という名前になります。origin は特別な意味を持つ予約語ではなく、単なる慣習的なあだ名です。
6. クローン（clone）#
リモートのリポジトリを、履歴ごと丸ごと手元にコピーすること。
「ダウンロード」との違いは、全履歴が付いてくる点です。クローンした瞬間から、過去のどの時点にも戻れます。
他人のプロジェクトを手元で動かしたいとき、あるいは自分のリポジトリを別のPCで扱いたいときに使います。
7. プッシュ（push）とプル（pull）#
push＝ローカルの変更をリモートに送る。pull＝リモートの変更をローカルに取り込む。
ローカル ──── push ────→ リモート（GitHub）
ローカル ←──── pull ──── リモート（GitHub）方向を覚えるコツは、自分を中心に考えることです。押し出す（push）のが送信、引き寄せる（pull）のが受信です。
似た言葉に fetch があります。fetch は「リモートの状態を取ってくるが、まだ手元のファイルには反映しない」という操作です。pull は fetch とマージを同時に行います。この違いは第6部の40で扱います。
8. フォーク（fork）#
他人のリポジトリを、自分のアカウントの下にコピーすること。
クローンとの違いは、コピー先です。
| コピー先 | 用途 | |
|---|---|---|
| clone | 自分のPC（ローカル） | 手元で作業したい |
| fork | 自分のGitHubアカウント（リモート） | 書き込み権限のないリポジトリに変更を提案したい |
他人のプロジェクトには直接 push できません。そこで fork して自分のコピーを作り、そこで変更し、「取り込んでください」と提案します。この提案が次の Pull Request です（第7部の48）。
9. プルリクエスト（Pull Request / PR）#
「この変更を取り込んでください」という提案。
GitHub の中心的な機能であり、Git の機能ではありません（GitLab では「Merge Request」と呼ばれます）。
Pull Request の画面では、次のことが1箇所でできます。
– 何が変わったかの差分表示
– 変更内容についての議論
– 行単位でのコメント（コードレビュー）
– 自動テストの結果表示
– 承認してからのマージ
チーム開発では、main への変更は必ず Pull Request を通すという運用が一般的です（第7部の45）。
10. イシュー（Issue）#
課題・バグ・要望を記録して議論する場所。
こちらも GitHub の機能です。「やること」を書き出しておく掲示板だと考えてください。
Issue と Pull Request の関係は、**Issue が「何をすべきか」、Pull Request が「こう直しました」**です。Issue で議論して方針を決め、Pull Request で実装を提案する、という流れが基本形になります（第7部の43）。
混同しやすいペア#
ここを押さえておくと、後の理解が速くなります。
| ペア | 違い |
|---|---|
| Git と GitHub | Git＝手元のソフト、GitHub＝クラウドのサービス（第1部の03） |
| clone と fork | clone＝PCにコピー、fork＝自分のGitHubアカウントにコピー |
| fetch と pull | fetch＝取得するだけ、pull＝取得して統合まで行う |
| commit と push | commit＝手元に記録、push＝それをGitHubに送る |
| merge と rebase | どちらも統合。履歴の形が変わる（第4部の25） |
とくに commit と push は別の操作です。コミットしただけでは GitHub には何も反映されません。ここは初心者が最も引っかかる点です。
GitHub固有の用語（Gitには存在しない）#
参考までに、どちらの世界の言葉かを整理しておきます。
| Gitの用語 | GitHubの用語 |
|---|---|
| リポジトリ、コミット、ブランチ、マージ、リモート、clone、push、pull、fetch、rebase、タグ | Pull Request、Issue、Fork、Star、Watch、Actions、Pages、Projects、Discussions、Organization |
左側は他のサービスに移っても通用します。右側は GitHub のサービス名です。
まとめ#
- リポジトリ＝履歴付きのフォルダ。コミット＝記録の最小単位
- ブランチはファイルのコピーではなく、コミットを指すポインタ
- ローカル（手元）とリモート（GitHub）の2箇所があり、push / pull で行き来する
- commit と push は別物。コミットしただけでは GitHub に反映されない
- Pull Request と Issue は Git の機能ではなく GitHub の機能
次のページ#
06. Gitのインストールと初期設定 ── ここから第2部に入ります。実際に Git を手元に入れて、最初の設定を行います。