3-1. 演習問題

問題1：選択問題

1-1. Git で迷ったとき、最初に実行するコマンドとして最も適切なのはどれか。

A. git status
B. git merge
C. git push

解答と解説

正解：A. git status

A が正しい。Git で迷ったときは、今どの branch にいて、何が未ステージで、何がステージ済みかを最初に把握する必要がある。
B は誤り。git merge は状態を確認する前に実行するコマンドではない。
C は誤り。git push は共有先へ変更を送る操作であり、状況確認なしに行うと危険である。

1-2. git add memo.txt の主な役割として最も適切なのはどれか。

A. memo.txt の変更を次の commit に入れる準備をする
B. memo.txt を完全に削除する
C. memo.txt をリモートへ送る

解答と解説

正解：A. memo.txt の変更を次の commit に入れる準備をする

A が正しい。git add は「次の commit にこの変更を入れる」と Git に伝える操作である。
B は誤り。ファイル削除の命令ではない。
C は誤り。リモートへ送るのは git push の役割である。

1-3. すでに git add した変更を、作業内容は残したままステージから外したい。最も適切なのはどれか。

A. git restore memo.txt
B. git restore --staged memo.txt
C. git commit -m "undo"

解答と解説

正解：B. git restore --staged memo.txt

B が正しい。git restore --staged は、ステージした変更を外すためのコマンドである。
A の git restore memo.txt は、作業ツリーの変更自体を戻す方向で使う。
C は誤り。新しい commit を作っても、「ステージから外す」ことにはならない。

「変更を消したい」のか、「次の commit から外したいだけ」なのかを区別することが重要である。

1-4. branch を使う主な理由として最も適切なのはどれか。

A. まだ完成していない変更を main から分離して作業するため
B. ファイルサイズを自動で小さくするため
C. ステータスコードを確認するため

解答と解説

正解：A. まだ完成していない変更を main から分離して作業するため

A が正しい。branch の主目的は、安全に作業を分けることにある。
B は誤り。branch にファイル圧縮の役割はない。
C は誤り。ステータスコードは HTTP の話であり、Git の branch とは無関係である。

1-5. merge conflict が起きやすい状況として最も適切なのはどれか。

A. 別々の branch で、同じファイルの同じ部分を別々に変更した
B. git status を 2 回続けて実行した
C. まだ 1 回も commit していない

解答と解説

正解：A. 別々の branch で、同じファイルの同じ部分を別々に変更した

A が正しい。同じ場所に対して異なる変更があると、Git はどちらを採用すべきか自動では決められない。
B は誤り。git status を何回実行しても conflict は起きない。
C は誤り。commit の回数そのものではなく、変更内容の衝突が本質である。

1-6. すでに commit 済みの変更を、履歴を壊さず安全に打ち消したい。最も適切なのはどれか。

A. git revert <commit>
B. git add <file>
C. git diff

解答と解説

正解：A. git revert <commit>

A が正しい。git revert は履歴を壊さず、既存 commit の内容を打ち消す新しい commit を作る。
B の git add はステージ操作であり、commit 済み変更の取消しではない。
C の git diff は差分確認用であり、履歴を打ち消す操作ではない。

特にチーム開発では、「消す」より「打ち消す」を優先すると安全である。

問題2：穴埋め問題

次の文章の空欄を埋めてください。

今編集中のファイルがある場所を （　　　） ツリーという。
次の commit に入れる変更を選ぶ場所を （　　　） エリアという。
変更履歴を記録する単位を （　　　） という。
新しい branch を作ってそのまま移動するコマンドは git switch -c **（　　　）** である。
ステージ済みの差分を見るコマンドは git **（　　　）** --staged である。
commit 済みの変更を安全に打ち消すコマンドは git **（　　　）** である。

解答欄

解答と解説

作業

今編集中のファイルがある場所を作業ツリーという。Git のコマンドで状態を見るときの出発点である。
ステージング

次の commit に入れる変更を選ぶ場所である。全部を一度に commit せず、意味のある単位に分けるために必要。
commit

履歴を記録する基本単位である。あとで戻ったりレビューしたりするときの最小単位になる。
feature/login

例として feature/login のような branch 名が入る。大切なのは「新しい branch 名を与え、その branch へ移動する」という意味である。
diff

git diff --staged で、ステージ済みの変更内容を確認できる。commit 前の最終確認としてよく使う。
revert

commit 済みの変更を安全に打ち消すコマンドである。履歴の整合性を保ちやすい。

問題3：記述問題

3-1. 作業ツリー・ステージングエリア・リポジトリの違いを説明してください。

解答欄

解答と解説

解答例

作業ツリーは今自分が編集している場所、ステージングエリアは次の commit に入れる変更を選ぶ場所、リポジトリは commit 履歴が保存される場所である。 Git はこの 3 つを分けて管理しているため、変更を見たり、選んだり、記録したりを段階的に行える。この構造を理解すると、git add や git restore --staged の意味が分かりやすくなる。

3-2. なぜ変更を小さく commit し、branch を分けて作業したほうがよいのか説明してください。

解答欄

解答と解説

解答例

変更を小さく commit すると、どの変更で問題が起きたかを追いやすくなる。また branch を分けて作業すると、未完成の変更を main に混ぜずに済むため安全である。レビュー、デバッグ、取り消しのすべてがやりやすくなるため、実務ではとても重要である。

3-3. git restore と git revert の違いを説明してください。

解答欄

解答と解説

解答例

git restore は、主に作業ツリーやステージングエリアの変更を戻すために使う。一方 git revert は、すでに commit した変更を打ち消す新しい commit を作る。つまり restore は commit 前の調整、revert は commit 後の安全な取消し、と整理できる。

3-4. Git の状態が分からなくなったとき、なぜ最初に git status を見るべきなのか説明してください。

解答欄

解答と解説

解答例

Git で困ったときは、今どの branch にいて、何が未ステージで、何がステージ済みかを把握しないと正しい判断ができない。 git status は、その全体像を最短で確認できるコマンドである。状態確認なしに戻す操作をすると、必要な変更まで消す危険があるため、まず git status を見る習慣が重要である。

問題4：ハンズオン

まずはブラウザ上の学習用 Git プレイグラウンドで状態変化を観察し、その後に Git Bash で同じ流れを再現してみましょう。

4-A. Playground で状態変化を観察する

このプレイグラウンドは xterm.js と isomorphic-git で動くブラウザ内の学習用 Git 環境です。Playground 上部に STEP 1 から順番にコマンドが表示されるので、今表示されている 1 コマンドだけを進めてください。手入力でも、入力欄に入れる / このコマンドを実行 ボタンでも進められます。

① 作業ツリー → ステージ → commit を見る

Git Playground

対応コマンドのみ実行できます / Enter で実行 / ↑ ↓ で履歴 / ← → でカーソル移動

xterm.js 上のターミナルでコマンドを打ち込み、ブラウザ内の Git リポジトリで Working Tree・Staging Area・Git Graph の変化を観察します。

いま入力するコマンド

ここに表示される 1 つのコマンドだけを、そのままターミナルに入力してください。正しい順に入力すると、次のステップへ自動で進みます。

1 最初の状態を見る
2 ファイルを変更する
3 変更が出たことを確認する
4 変更をステージする
5 登録した差分を見る
6 commit を作る

ステップ完了後に自由に試すコマンド（クリックで入力欄へ）

ターミナル

現在の状態

Working Tree

Staging Area

Git Graph

STEP 1 から順に最後まで進められれば成功です。

確認ポイント：

変更直後は Working Tree にだけ変化がある
git add 後は Staging Area に変更が移る
git commit 後は Staging Area が空になり、Git Graph に commit が 1 つ増える

② branch と merge を見る

Git Playground

対応コマンドのみ実行できます / Enter で実行 / ↑ ↓ で履歴 / ← → でカーソル移動

branch を切り、feature branch で commit し、merge する流れをブラウザ内の Git リポジトリで CLI 風に試します。

いま入力するコマンド

ここに表示される 1 つのコマンドだけを、そのままターミナルに入力してください。正しい順に入力すると、次のステップへ自動で進みます。

1 branch を確認する
2 新しい branch を作る
3 branch 側で変更を作る
4 変更が見えているか確認する
5 変更をステージする
6 feature branch で commit する
7 main に戻る
8 merge して合流させる

ステップ完了後に自由に試すコマンド（クリックで入力欄へ）

ターミナル

現在の状態

Working Tree

Staging Area

Git Graph

ここでも STEP 1 から順に最後まで進められれば成功です。

確認ポイント：

feature/add-note という branch ラベルが増える
feature branch の先にだけ commit が増える
merge 後は合流 commit が作られ、グラフで枝分かれと合流が見える

4-B. Git Bash で同じ流れを再現する

Playground で観察した内容を、今度は実際の Git Bash で再現します。

事前準備

次の作業は ~/practice/git-basics という練習用フォルダで行います。間違えてもこのフォルダの中だけなので、安心して試してください。

① 練習用リポジトリを作る

mkdir -p ~/practice/git-basics
cd ~/practice/git-basics
git init
git branch -m main
git config user.name "Trainee"
git config user.email "trainee@example.com"
git status

次のような表示が出れば成功：

On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

On branch main が出ていれば、Git 管理が始まっている
No commits yet は、まだ何も記録していない状態を意味する

② 最初の commit を作る

echo "Git practice" > memo.txt
git status
git add memo.txt
git status
git commit -m "Add initial memo"
git --no-pager log --oneline

git status を 2 回実行しているのがポイント。表示の変化を追うこと：

# 1回目の git status（add 前）
Untracked files:
        memo.txt            ← まだ Git が追跡していない

# 2回目の git status（add 後）
Changes to be committed:
        new file:   memo.txt  ← 次の commit に入る準備ができた

commit 後の git --no-pager log --oneline で、履歴が 1 件表示されれば成功：

a1b2c3d Add initial memo

（a1b2c3d の部分は環境ごとに異なる）

③ 未ステージの変更を確認して戻す

echo "Second line" >> memo.txt
git --no-pager diff
git restore memo.txt
git status

git --no-pager diff で、追加した行が緑色の + 付きで表示される：

Git practice
Second line

git restore memo.txt の後、git status で次のように表示されれば成功：

On branch main
nothing to commit, working tree clean

working tree clean は「作業ツリーに未保存の変更がない」という意味
つまり restore で変更が取り消され、commit 済みの状態に戻っている

④ ステージしすぎた変更を戻す

echo "Second line" >> memo.txt
git add memo.txt
git status
git --no-pager diff --staged
git restore --staged memo.txt
git status
git --no-pager diff

git add 後の git status では、変更が「次の commit に入る予定」になっている：

Changes to be committed:
        modified:   memo.txt

git restore --staged 後の git status では、ステージから外れて「未ステージ」に戻る：

Changes not staged for commit:
        modified:   memo.txt

ここで重要なのは、ステージから外れただけで、編集内容自体は消えていない こと。 git --no-pager diff を実行すると、まだ差分が表示される：

Git practice
Second line

⑤ 変更を commit してから、安全に打ち消す

git add memo.txt
git commit -m "Add second line to memo"
git --no-pager log --oneline --graph
git revert HEAD --no-edit
git --no-pager log --oneline --graph

revert 前の git log では commit が 2 件：

* b2c3d4e Add second line to memo
* a1b2c3d Add initial memo

revert 後の git log では、打ち消し commit が追加されて 3 件になる：

* c3d4e5f Revert "Add second line to memo"
* b2c3d4e Add second line to memo
* a1b2c3d Add initial memo

元の commit（b2c3d4e）は消えておらず、逆向きの commit が上に追加 されている
これが「履歴を消す」ではなく「打ち消す」ということ

⑥ branch を作って merge する

git switch -c feature/add-note
echo "Branch note" > note.txt
git add note.txt
git commit -m "Add branch note"
git switch main
git merge --no-ff feature/add-note -m "Merge feature/add-note"
git --no-pager log --oneline --graph --all

git switch -c feature/add-note で新しい branch に切り替わる：

Switched to a new branch 'feature/add-note'

merge 後の git --no-pager log --oneline --graph --all で、枝分かれと合流が見える：

*   d4e5f6a Merge feature/add-note
|\
| * e5f6a7b Add branch note
|/
* c3d4e5f Revert "Add second line to memo"
* b2c3d4e Add second line to memo
* a1b2c3d Add initial memo

|\ と |/ の部分が、branch が分かれて合流したことを表している
--no-ff を付けたので、merge commit（d4e5f6a）が明示的に作られている

⑦ 迷ったら状態を見る

途中で分からなくなったら、必ず次の順で確認する。

git status
git --no-pager diff
git --no-pager diff --staged
git --no-pager log --oneline --graph --all