Git基礎図解ガイド｜コミット・ブランチ・マージ・プッシュ・デプロイ

コミット ── 作業のスナップショット

commit ／セーブポイントを積み重ねて「履歴」を作る

コミットとは「この時点のファイル全体の状態を丸ごと記録する」操作です。ゲームのセーブポイントのようなもので、記録した時点にはいつでも戻れます。作業に区切りがつくたびにコミットしておくことで、変更の履歴が時系列に積み上がっていきます。

図1：コミットが時系列に積み重なって履歴になる

各コミットには「誰が・いつ・何を・なぜ変更したか」が記録されます。後から「この変更はどういう意図だったのか」を追跡できるのが最大の価値です。

実務でのイメージ就業規則の改訂履歴と同じ発想です。「第◯版・改訂日・改訂者・改訂理由」を版数管理するように、コードの変更も1件ずつ記録していきます。

# 変更をステージに載せて、メッセージ付きで記録する
git add .
git commit -m "勤怠集計ロジックを追加"

branch ／安定版はそのまま、別ラインで安全に試す

ブランチとは「履歴の枝分かれ」です。本流（mainブランチ）は本番稼働中の安定版としてそのままにしておき、新機能の開発や修正は枝分かれさせた作業用ブランチで進めます。

図2：mainから作業用ブランチを分岐させる

分岐したあとは互いに影響しません。作業用ブランチで失敗しても、mainは無傷のまま。「本番は動かしたまま、隣で新しいものを試す」ことができる仕組みです。

実務でのイメージお客様に納品済みの給与計算シートは触らず、コピーを作って新しい計算式を検証するのと同じです。検証が済んだものだけを正式版に反映します。

# mainから作業用ブランチを作って切り替える
git checkout -b feature-kintai

merge ／完成した変更をmainに統合する

作業用ブランチでの開発が完成したら、その変更をmainに「合流」させます。これがマージです。合流地点には「マージコミット」が作られ、両方のブランチの変更が1つに統合されます。

図3：featureブランチがmainに合流する

押さえておきたい2つのポイント

コンフリクト（衝突）：同じ箇所を双方で変更していると衝突が起き、どちらを採用するか手動で選ぶ必要があります。
プルリクエスト：GitHubでは通常、マージの前に「プルリクエスト（PR）」を作り、他のメンバーのレビューを挟んでからマージします。品質チェックの関所です。

# mainに戻ってfeatureブランチを取り込む
git checkout main
git merge feature-kintai

push / pull ／ローカルとリモートをつなぐ

ここまでの操作は、すべて自分のPC内（ローカルリポジトリ）で完結する話です。プッシュで初めて、GitHubなどのリモートリポジトリに履歴が送られ、チームのメンバーと共有されます。逆に、他のメンバーが送った変更を自分のPCに取り込むのがプルです。

図4：ローカルとリモートの関係（push＝提出、pull＝受領）

実務でのイメージ自分の机で作った書類（ローカル）を、事務所の共有キャビネット（GitHub）に提出するのがpush。キャビネットから最新版を取ってきて自分の机に置くのがpullです。

# リモートに送る／リモートから受け取る
git push origin main
git pull origin main

deploy ／完成したコードを実際のユーザーに届ける

デプロイはGitの操作ではなく、「完成したコードを実際にユーザーが使えるサーバーに配置する」工程です。Vercelなどのサービスを使っている場合、mainブランチへのプッシュ（マージ）が自動デプロイのトリガーになります。この自動化の仕組みをCI/CDと呼びます。

図5：コミットから本番公開までの全体フロー

デプロイで知っておきたいこと

5つの操作がひとつの流れになる

日々の開発は、次のサイクルの繰り返しです。料理に例えるなら「下書きを保存 → 別レシピを試作 → 良かったものを本レシピに統合 → レシピ帳を共有棚に置く → お客様に提供」という流れになります。