Git・GitHub用語入門。commit、branch、pushを整理

「保存して、コミットして、プッシュしておいて」。こんな説明を初めて聞くと、「全部保存のことじゃないの？」となりますよね。

実は、それぞれ変更が届く場所が違います。今回は、学習ノートの説明文を1行直す場面を使い、手元のファイルからGitHubへ届くまでを追います。操作前の用語整理として読んでみてください。

まずは3つだけ覚えよう

保存：今のファイルを更新する
commit：選んだ内容を、Gitの履歴へ記録する
push：その履歴を、GitHubなどの接続先へ送る

この3段階を分けるだけで、変更が反映されない場面をかなり整理できます。GitHubの画面が古いとき、エディターの保存ボタンを何度押しても、まだpushしていなければ届きません。

GitとGitHubの違い

Gitは、ファイルの変更履歴を管理する道具です。GitHubは、Gitのリポジトリをオンラインで共有し、相談や確認も行えるサービスです。

比較	Git	GitHub
主な役割	内容の履歴を記録・比較する	履歴や変更案を共有する
オフラインの作業	コミットや履歴確認ができる	サービスとの通信には接続が必要
使う場所	自分のPCなど	Web上のサービス

GitはGitHub専用ではなく、ほかの共有先にも接続できます。逆に、GitHubのWeb画面でファイルを編集しても、その内容が自分のPCへ自動で入るとは限りません。

自分のPC側をローカル、接続して使う別のリポジトリ側をリモートと呼びます。まずは「どちらに変更があるか」を意識してください。

リポジトリとコミット

ファイルの保存だけでは履歴は増えない

リポジトリは、Gitが履歴を管理する場所です。通常のフォルダーにある作業ファイルと、その変更をたどるための管理情報を扱います。

例えばREADMEの説明が次のように変わったとします。

変更前：Pythonを勉強しています。
変更後：Pythonで計算ツールを作っています。

エディターで保存すると、現在のファイルは新しい内容になります。ただし、それだけでは「いつ、なぜ変えたか」というGitの記録は増えません。

記録する内容を選んでからコミットする

変更を選ぶ操作がステージング、選んだ内容を説明付きで残す操作がコミットです。

作業ファイル → ステージ → コミット
今編集中       次に記録する内容   履歴に残った内容

ステージへ入れるコマンドは git add、履歴を作るコマンドは git commit です。2つのファイルを編集していても、1つだけを今回の記録へ選ぶことができます。

コミットはゲームのセーブポイントに似ていますが、「フォルダーの全部が自動で保存される」わけではありません。ステージした時点の内容が対象です。addした後にまた編集したなら、その追加編集を記録するには選び直します。

コミットには、内容を区別するIDとメッセージが付きます。「READMEの学習内容を更新」のような説明にすると、後で探しやすくなります。具体的な練習はGit実践①で行えます。

ブランチ、マージ、コンフリクト

ブランチは履歴の流れに付ける名前

ブランチは、あるコミットを先頭とする履歴の流れに付ける名前です。例えば main を公開用の流れ、feature/profile を自己紹介を直す流れとして使えます。

ブランチを作っても、別の物理フォルダーが増えるわけではありません。通常は同じフォルダーで切り替え、そのブランチの内容を編集します。

「mainなら必ず完成版」というGitの決まりもありません。安定した内容をmainへ置く運用を、自分たちで決めています。また未コミットの編集は、ブランチ間で持ち越されたり、切り替えを止めたりすることがあります。ブランチだけで未記録の作業まで隔離できるわけではない点に注意しましょう。

変更を取り込むのがマージ

マージは、別の履歴の変更を現在のブランチへ統合する操作です。

自己紹介の変更を採用するなら、mainへ移ってから作業ブランチをマージします。取り込む側と取り込まれる側があるので、「どちらにいるか」を先に確かめます。

Gitが選べない変更は、人が決める

コンフリクトは、両方の変更を自動でまとめられない状態です。同じ見出しを一方で「学習記録」、もう一方で「制作日記」へ変えた場合、Gitにはどちらが適切か分かりません。

故障やデータ消失とは限りません。両方の意図を読み、残す完成形へ編集して記録します。「学習と制作の記録」のように両方を生かす判断もできます。

実際の印の読み方と解決方法は、ブランチとマージの記事で順番に説明します。

clone（クローン）とfork（フォーク）

両方とも「コピー」に見えますが、目的と置き場所が違います。

操作	この学習でのコピー先	何に使うか
clone	自分のPC	編集できる作業環境と履歴を手元へ作る
fork	自分のGitHubアカウント側	元と関連付いた別のリポジトリで変更案を作る

cloneは、リポジトリの履歴を複製します。一般的なcloneでは、元への接続情報も設定されるため、後で新しい変更を取得できます。ただし取得方法によって履歴の範囲は変わる場合があります。

forkは、GitHub上で元のリポジトリを基に別のリポジトリを作る仕組みです。他人のプロジェクトへ直接書き込む権限がなくても、自分のforkで変更案を用意できます。

よくある流れは「GitHub上でfork → 自分のPCへclone → 編集」です。forkだけではPCへファイルが置かれない、cloneだけでは元へ書き込む権限が増えない、と分けると迷いません。

また、公開されているコードでも、自由な再配布が許されているとは限りません。利用・配布するときはライセンスも確認してください。

push（プッシュ）とpull（プル）

pushは、ローカルのコミットを接続先へ送る操作です。未保存・未コミットの編集を全部送る操作ではありません。

pullは、接続先から履歴を取得し、現在のブランチへ統合する操作です。単なるダウンロードより一歩先まで進みます。統合方法は設定や指定によって変わります。

今ある変更	次に必要な操作の例
PCで保存しただけ	addで選び、commitする
PCでcommit済み、GitHubは古い	pushする
GitHubだけが新しい	内容を確認してpullする
両方が別々に新しい	履歴を確認し、まとめ方を決める

取得だけして内容を確認したいときは fetch を使います。現在の作業ブランチへすぐ統合しないので、両側が変わった場面で確認しやすくなります。

接続先によく付ける origin という名前も出てきますが、「GitHubそのもの」の意味ではありません。そのリポジトリで決めた接続先の別名です。pushとpullの実践で確認できます。

Pull Requestとは

Pull Request（PR）は、「この変更を別のブランチへ取り込みませんか」という提案をまとめる場所です。GitHubの機能で、変更点の確認、コメント、テスト結果などを扱えます。

例えば記事の説明を直すなら、PRへ次を書くと判断しやすくなります。

何が分かりにくかったのか
どの説明をどう直したのか
リンクや表示をどう確認したのか

pull コマンドと名前は似ていますが、同じ操作ではありません。pullは手元で履歴を取り込む操作、PRは取り込みを相談・確認する仕組みです。

一人の制作でも、公開前に差分を見直す区切りに使えます。ただしPRを作っただけで、必ず自動的にmainへ入るわけではありません。最終的にマージする段階が別にあります。

基本の流れ

共同作業の一例を順番に追います。

リポジトリをcloneする
作業用ブランチを作る
ファイルを編集・保存する
差分を読み、必要な内容をステージする
コミットしてローカルへ記録する
pushしてGitHubへ送る
PRで確認し、問題がなければマージする

すべてのプロジェクトが同じ運用ではありませんが、「編集」「記録」「共有」「統合」を分ける点は役立ちます。

確認問題：変更はどこにある？

問題1：保存してコミットもしましたが、GitHubには古い内容が出ています。次に確認する段階はどこでしょうか。

問題2：PRを作ったのに、mainの内容が変わりません。故障と判断してよいでしょうか。

模範解答と解説

pushできているか、送信先とブランチが正しいかを確認します。コミットは手元の履歴なので、それだけでは共有先に届きません。
まだマージされていない可能性があります。PRは変更の提案であり、作成と統合は別の段階です。PRの状態を確認します。

まとめ

まずは「保存・コミット・push」を区別できれば十分です。用語を一度に暗記するより、「自分の変更が今どこにあるか」をたどってみてください。

実際に履歴を作りたくなったら、Git実践①から始めましょう。