3-1. Gitの基礎

このセクションで学ぶこと

バージョン管理が必要な理由
Git が見ている 3 つの場所（作業ツリー・ステージングエリア・リポジトリ）
commit・branch・merge の基本
間違えたときに、まず何を見て、どう安全に戻すか

1. バージョン管理とは何か

バージョン管理とは、ファイルの変更履歴を記録し、必要に応じて過去の状態へたどれるようにする仕組み である。

プログラムを書いていると、次のようなことがよく起きる。

昨日まで動いていたのに、今日の変更で動かなくなった
どのファイルを、なぜ変えたのか分からなくなった
複数人が同じプロジェクトを触り、変更がぶつかった

ファイル名を report_final.txt、report_final_v2.txt、report_final_really_final.txt のように増やして管理する方法では、履歴も意図も追いにくい。

手作業の管理

report.txt
report_final.txt
report_final_v2.txt
report_final_really_final.txt

Git を使うと、変更は commit（コミット） という単位で記録される。

Git の管理

A -- B -- C -- D

A: 最初の状態
B: README を追加
C: 入力チェックを追加
D: 不要なログを削除

これにより、「いつ」「何を」「どんな意図で」変えたかを追いやすくなる。

なぜ新人エンジニアに Git が重要なのか

Git は単にコードを保存する道具ではない。
変更を小さく分ける習慣、危険な変更を分離する習慣、問題が起きたら履歴から追う習慣 を作るための道具でもある。

特に実務では、次の 3 点が重要になる。

変更前後の差分を確認する
安定している状態を壊さないよう、枝分かれして作業する
間違えたときに、慌てて上書きせず履歴と状態を見て戻す

2. Git が見ている 3 つの場所

初心者が Git で混乱しやすい理由の 1 つは、ファイルが 1 か所だけで管理されているわけではない からである。

Git を理解するうえで重要なのは、次の 3 つの場所である。

場所	役割	よく使うコマンド
作業ツリー（Working Tree）	今まさに編集中のファイルがある場所	`git status`, `git diff`, `git restore`
ステージングエリア（Staging Area / Index）	次の commit に入れる変更を選ぶ場所	`git add`, `git restore --staged`, `git diff --staged`
リポジトリ（Repository）	commit として履歴が保存される場所	`git commit`, `git log`

作業ツリー  -- git add -->  ステージングエリア  -- git commit -->  リポジトリ
    ^                              |
    |                              |
    └------ git restore ---------- └-- git restore --staged

3 つの場所をどう考えるか

作業ツリー は「いま手で編集している机の上」
ステージングエリア は「次に提出する変更だけをまとめるトレー」
リポジトリ は「提出済みの記録庫」

この 3 つを区別できると、git add や git restore が急に分かりやすくなる。

まず見るべきは `git status`

迷ったとき、最初に実行するコマンドはほぼ git status である。

git status

git status では主に次のことが分かる。

どのブランチにいるか
変更されたファイルは何か
その変更がステージ済みか、未ステージか
commit されていない変更があるか

Git のトラブルで大切なのは、すぐ消すことではなく、先に状態を把握すること である。

差分を見る

git diff
git diff --staged

git diff は、作業ツリーとステージングエリアの差分を見る
git diff --staged は、ステージングエリアと最後の commit の差分を見る

つまり、今の変更が「まだ提出前なのか」「次の commit に入る予定なのか」を分けて確認できる。

Git Bash では、git diff や git log の表示が長いと pager が開き、画面が止まったように見えることがある。
その場合は慌てず q を押せば戻れる。研修の演習では混乱を避けるため、git --no-pager ... と書く場合もある。

3. commit とは何か

commit とは、その時点の変更を意味のある単位で履歴に記録すること である。

commit は何を記録しているのか

初心者は「Git は変更行だけ覚えている」と感じやすいが、実際には その時点のファイル集合のスナップショット を記録していると考えると理解しやすい。

commit A: README.md だけある
commit B: README.md と app.js がある
commit C: README.md と app.js の中身が更新された

そのため commit は、「あとで戻れる保存ポイント」であると同時に、「どの変更を 1 つの意味として扱うか」という設計単位でもある。

小さく commit する理由

たとえば次の 2 つを比べる。

悪い例
- 画面変更
- API変更
- バグ修正
- 不要ファイル削除
を全部まとめて 1 commit

良い例
- 入力フォームを追加
- バリデーションを追加
- エラーメッセージを修正
を別々に commit

小さく commit しておくと、後から次のことがしやすくなる。

どの変更で壊れたか特定しやすい
レビューしやすい
不要な変更だけを取り消しやすい

よく使う基本コマンド

git init
git status
git add memo.txt
git commit -m "Add initial memo"
git --no-pager log --oneline

コマンド	役割
`git init`	Git 管理を開始する
`git add <file>`	次の commit に入れたい変更をステージする
`git commit -m "..."`	ステージした変更を履歴に記録する
`git --no-pager log --oneline`	commit 履歴を短く見る

4. branch とは何か

branch（ブランチ）とは、履歴の途中から安全に作業を分けるための枝 である。

実務では、安定した main ブランチとは別に、機能追加や修正ごとにブランチを切って作業することが多い。

A -- B -- C  (main)
          \
           D -- E  (feature/login)

なぜ branch を使うのか

branch を使わずに main へ直接変更を重ねると、未完成の変更や失敗した変更がすぐ共有ラインへ混ざってしまう。

branch を使うと、次の利点がある。

まだ完成していない作業を main から分離できる
複数人が別々の変更を並行して進めやすい
問題が起きても、どの変更系列に問題があるか追いやすい

branch は「履歴のコピー」ではなく「ラベル」

初学者は branch を「巨大な複製」と思いがちだが、まずは ある commit を指しているラベル と考えると理解しやすい。

A -- B -- C  (main)
          ^
          いま main は C を指している

新しい branch を作ると、その commit から別のラベルが伸びる。

git switch -c feature/readme

これは「feature/readme という新しい branch を作り、そこへ移動する」という意味である。

5. merge とは何か

merge（マージ）とは、別の branch で行った変更を、現在の branch へ取り込むこと である。

たとえば feature/readme で作業が終わったら、main に取り込む。

A -- B -- C -------- F  (main)
          \        /
           D -- E    (feature/readme)

基本的な流れ

git switch main
git merge feature/readme

このとき Git は、両 branch の差分を見て自動でまとめようとする。

merge conflict（マージ衝突）

同じファイルの同じ部分を別 branch で別々に変更していると、自動では決められず conflict が起きる。

main で 3 行目を変更
feature でも同じ 3 行目を変更
↓
どちらを採用するか Git だけでは決められない

conflict が起きたときは、慌てて消すのではなく次の順に確認する。

git status で conflict 中だと確認する
ファイルを開いて、どの内容を残すか決める
修正後に git add <file> で解決済みにする
ふたたび commit してマージを完了する

ここでも重要なのは、「まず状態を見る」「どの変更がぶつかったかを理解する」である。

6. 間違えたときの確認順と安全な戻し方

Git を学び始めた段階では、強く消すコマンド より 安全に確認して戻すコマンド を優先したほうがよい。

迷ったときの確認順

1. git status
2. git --no-pager diff
3. git --no-pager diff --staged
4. git --no-pager log --oneline --graph --all

この順で見ると、「どこに変更があるのか」「まだ commit 前か」「すでに履歴に入ったか」を切り分けやすい。

よくある場面と安全な対処

状況	まず使うコマンド	何が起きるか
ファイルを編集したが、この変更を捨てたい	`git restore memo.txt`	作業ツリーの変更を取り消す
`git add` しすぎた	`git restore --staged memo.txt`	ステージから外す
何を変えたか分からない	`git --no-pager diff` / `git --no-pager diff --staged`	差分を見て判断できる
どの commit があるか確認したい	`git --no-pager log --oneline --graph --all`	履歴を短く見られる
commit 済みの変更を安全に打ち消したい	`git revert <commit>`	履歴を壊さず逆向きの commit を作る

git restore memo.txt は変更を消すコマンドなので、実行前に git --no-pager diff で「本当に捨ててよい変更か」を確認することが大切である。

`git revert` が安全な理由

すでに commit した変更を「なかったことにしたい」場面では、初心者はすぐ履歴を書き換えたくなることがある。
しかし共有済みの履歴を書き換えると、他の人の履歴と食い違いやすい。

そこでまず覚えるべきなのが git revert である。

git revert HEAD

git revert は、元の commit を消すのではなく、その変更を打ち消す新しい commit を追加する。

A -- B -- C -- D
               \
                E  (D を打ち消す commit)

このため、「取り消した」という事実も履歴に残り、チームでも追いやすい。

まずは安全な戻し方を身につける

研修のこの段階では、まず次の考え方を身につければ十分である。

消す前に git status
差分を見るなら git diff
ステージ解除は git restore --staged
commit 済みの安全な取り消しは git revert

慣れるまでは、履歴を大きく書き換えるコマンドよりも、状態を見ながら安全に戻す習慣 を優先しよう。

まとめ

キーワード	説明
バージョン管理	変更履歴を記録し、追跡・復元しやすくする考え方
作業ツリー	今編集中のファイルがある場所
ステージングエリア	次の commit に入れる変更を選ぶ場所
リポジトリ	commit 履歴が保存される場所
commit	意味のある変更単位の記録
branch	安全に作業を分けるための枝
merge	別 branch の変更を取り込むこと
`git status`	まず最初に状態を確認するコマンド
`git diff`	変更内容の差分を見るコマンド
`git restore`	作業ツリーやステージの変更を戻すコマンド
`git revert`	commit 済みの変更を安全に打ち消すコマンド

次のステップ

演習問題に取り組んで、状態確認と安全な戻し方を実際に試そう。

理解できたら 3-2. GitHub/GitLabでのチーム開発フローへ進もう。