GitとGitHubの違いから始める初心者用語集。コミット・プッシュ・プル・デプロイを順番で理解する
Gitを使い始めると、コミット、プッシュ、プル、マージなど、それまで聞いたことのない言葉が一度に出てきます。筆者も最初の頃は、それぞれが「保存」なのか「送信」なのか「公開」なのか分かりませんでした。
この混乱は、用語を一つずつ暗記するより、どこにある変更を、どこへ動かす操作なのかで整理すると解消しやすくなります。この記事では、GitとGitHubを使う流れに沿って、最初に知っておきたい12語をまとめます。
最初に、GitとGitHubは別のもの
Gitは、ファイルの変更履歴を自分のパソコンで管理できる仕組みです。編集前の状態へ戻ったり、変更を目的ごとに分けたりできます。
GitHubは、Gitで管理したプロジェクトをオンラインへ置き、ほかの人と共有したり変更をレビューしたりするサービスです。Gitが履歴を作る道具、GitHubがその履歴を共有する場所です。
GitHub DesktopやSourceTreeを使っているとGitを直接操作している感覚が薄くなりますが、画面上のCommit、Push、PullなどのボタンはGitの処理を実行しています。
まず覚えたいのは「保存場所が3段階ある」こと
Gitを難しく感じる大きな理由は、変更が一度にGitHubへ保存されるのではなく、段階を通って移動することです。
- 作業中のファイル：エディターで保存した状態
- ローカルリポジトリ：コミットとして自分のパソコンへ記録した状態
- リモートリポジトリ：プッシュしてGitHubへ共有した状態
さらに、GitHubへ送った内容をWebサイトやアプリとして利用できる状態にするのがデプロイです。
| 操作 | 何が起きる？ | GitHubは変わる？ | 公開サイトは変わる？ |
|---|---|---|---|
| ファイルを保存 | 作業中のファイルが更新される | 変わらない | 通常は変わらない |
| コミット | 変更がローカルの履歴になる | 変わらない | 通常は変わらない |
| プッシュ | コミットがリモートへ送られる | 変わる | 設定によっては変わる |
| デプロイ | 成果物が利用環境へ反映される | 必須ではない | 変わる |
作業を始めるまでの3語
1. リポジトリ：プロジェクトと履歴の入れ物
リポジトリは、プロジェクトのファイルとGitの変更履歴を管理する単位です。手元のものをローカルリポジトリ、GitHub上のものをリモートリポジトリと呼びます。
2. クローン：GitHubのリポジトリを手元へ作る
クローンは、リモートリポジトリを履歴ごと自分のパソコンへ複製する操作です。通常はプロジェクトで最初に一度行い、その後は同じフォルダで作業します。
3. ブランチ：変更を本流から分ける
ブランチは、変更履歴を枝分かれさせる作業ラインです。公開に使うmainを直接変更せず、作業ブランチで試してから統合できます。
変更を記録する2語
4. ステージング：次のコミットへ入れる変更を選ぶ
ステージングは、編集した変更の中から次のコミットへ含めるものを選ぶ工程です。コマンドではgit addを使います。
一つのファイルに複数の変更があっても、目的に合うものだけを選べます。コミット前に不要なファイルや秘密情報が入っていないか確認する場所でもあります。
5. コミット：選んだ変更をローカルの履歴へ残す
コミットは、選んだ変更を説明メッセージとともにGitの履歴へ記録する操作です。通常は自分のパソコン内へ保存され、まだGitHubには送られません。
「更新」だけでなく「用語検索へ読み仮名を追加」のようなメッセージを付けると、あとで履歴を追いやすくなります。
GitHubとやり取りする2語
6. プル：GitHubの新しい変更を手元へ取り込む
プルは、リモートの変更を取得し、現在のローカルブランチへ統合する操作です。ほかの人や別のパソコンで進んだ変更を手元へ反映します。
単なるダウンロードではなく、標準的には「取得して統合」まで行います。自分の未コミットの変更がある場合は、先に状態を確認しましょう。
7. プッシュ：ローカルのコミットをGitHubへ送る
プッシュは、ローカルで作ったコミットをリモートリポジトリへ送る操作です。コミットとプッシュが別になっているため、インターネットにつながっていない状態でも履歴だけ先に作れます。
ほかの変更が先にリモートへ入っているとプッシュを拒否されることがあります。いきなり強制プッシュせず、プルやフェッチで状況を確認します。
変更をmainへ入れる2語
8. プルリクエスト：変更を取り込む前の確認場所
プルリクエストは、作業ブランチの変更をmainなどへ取り込む前に、差分の確認やレビューを行うGitHubの機能です。「PR」「プルリク」とも呼ばれます。
git pullとは別物です。名前にプルが入っていますが、ブランチ間の変更を相談し、マージを提案する場所です。
9. マージ：二つのブランチを統合する
マージは、あるブランチの変更を別のブランチへ統合する操作です。同じ箇所が違う内容に変更されていると、マージコンフリクトが発生します。
コンフリクトは故障ではなく、Gitだけではどちらが正しいか決められない状態です。両方の意図を確認して、人が残す内容を選びます。
利用者へ届ける最後の1語
10. デプロイ：Webサイトやアプリを使える状態にする
デプロイは、作成したWebサイトやアプリをサーバーなどへ配置し、利用者が使える状態にすることです。Gitの履歴操作ではありません。
プッシュとデプロイは別ですが、mainへのプッシュやマージをきっかけに自動デプロイするプロジェクトもあります。この場合はPushボタンが公開の入口になるため、事前確認が重要です。
一連の流れで並べるとこうなる
- リポジトリをクローンする
- mainから作業ブランチを作る
- ファイルを編集・保存する
- 変更をステージングする
- コミットしてローカル履歴へ残す
- 必要ならプルでリモートの更新を取り込む
- プッシュして作業ブランチをGitHubへ送る
- プルリクエストで変更を確認する
- 問題がなければmainへマージする
- 本番環境へデプロイする
小さな個人サイトでは、ブランチやプルリクエストを省略することもあります。一方、複数人で作る場合や自動デプロイがある場合は、確認の段階を分けるほど事故を防ぎやすくなります。
AIにGit操作を頼むときも意味は同じ
GitHub CopilotやCodexなどは、ファイル編集だけでなくGitの状態確認やコミットを補助できます。しかし、AIが操作してもコミット、プッシュ、デプロイの影響範囲は変わりません。
特にプッシュやデプロイは、自分のパソコンの外へ影響が出る操作です。次の3点を確認してから任せます。
- どのリポジトリ・ブランチを操作するのか
- コミットへ何が含まれるのか
- プッシュ後に自動デプロイが動くのか
最初はAIへ「実行せず、現在の状態と必要な操作だけ説明してください」と頼むのも有効です。意味が分からないコマンドをそのまま実行するより、差分と影響を確認する習慣を先に作りましょう。
最初は4つの区別だけでも十分
すべてを一度に覚えなくても、まずは次の区別がつけば日常の操作を理解しやすくなります。
- コミット：手元の履歴へ記録する
- プル：共有先の変更を手元へ取り込む
- プッシュ：手元の履歴を共有先へ送る
- デプロイ：利用者が使う環境へ反映する
エラーが出たときも、「いま変更はどこにあり、どこへ動かそうとしているか」を考えると、原因を切り分けやすくなります。
参考情報
- Git公式：Git tutorial
- Git公式：Git glossary
- GitHub Docs：Getting started with Git
- GitHub Docs：About repositories
- GitHub Docs：Deploying with GitHub Actions
公式情報の確認日：2026年7月21日
