3️⃣

【理解度チェック】ローカルで手を動かすGitトラブル実技テスト【実践編】

に公開
Git
理解度チェック
実技テスト
idea

1. はじめに

これまでクイズ形式で Git の知識を確認してきましたが、
Git は手を動かして “失敗して直す” ことで一気に理解が深まるツール です。

そこで今回は、ローカル環境で実際にコマンドを打ちながら取り組める
「実技テスト形式」の5問 を用意しました。
コマンドの勉強のために全てコマンドで解決を目指す記事としていますので、GitLabやGitHubなどでの作業は行いません。

  • すべてローカルの適当なディレクトリで完結

  • 既存プロジェクトを壊さないように、必ず 練習用フォルダ で実施

  • 各問題ごとに

    1. 状況（シナリオ）
    2. 目標（ゴール）
    3. チェック方法
    4. 解答例（サンプル手順）

という構成にしています。

この実技テストには、ここで紹介する「解答例」以外にも、いろいろなやり方があります。
別解も大歓迎ですし、自分なりの手順でゴールにたどり着けたらそれで正解 と考えてOKです。
「こういうやり方もあるよ」という視点で読んでもらえたらうれしいです。

また、実技テストとして出題する内容の一部は、あえて「やらかしてから直す」流れを体験してもらう内容にしています。
本番リポジトリでは試しにくい操作も、練習用ディレクトリなら安心して壊してOKです。
失敗を怖がらずに、「どうやって元に戻せるか？」を考えながら、ぜひ何度も遊んでみてください。

2. 実技テスト問題

共通準備

どの問題も、まずは練習用ディレクトリを作ってください。

mkdir git-practice
cd git-practice

各問題ごとに、新しいサブディレクトリ を作ってその中で作業すると安全です。
例：practice01, practice02, … など。

問題1：基本フローを一人で回す（init / add / commit / branch / merge）

1-1. 状況

あなたは新しく小さなスクリプトを書くことになりました。
Git で履歴を残しながら、以下の流れを一通りこなしてください。

1-2. 目標（やることリスト）

  1. practice01 ディレクトリを作成して、その中で Git リポジトリを初期化する
  2. hello.txt を作成し、1行メッセージを書いてコミットする
  3. feature/add-second-line ブランチを作成して切り替える
  4. hello.txt に2行目を追加してコミットする
  5. main に戻し、feature/add-second-line をマージする

1-3. チェック方法

  • git log --oneline --graph で、main に2つのコミットがあること
  • hello.txt に2行分のメッセージが書かれていること

問題2：間違ったブランチでコミットしてしまった！（cherry-pick / reset）

2-1. 状況

本当は feature/new-ui で作業するつもりだったのに、
うっかり main で変更してコミットしてしまいました。

まだリモートには push していない前提です。

2-2. 目標（やることリスト）

  1. practice02 ディレクトリでリポジトリを作成
  2. main で app.txt を作って1回コミット
  3. 本当は feature/new-ui でやるべき変更を、わざと main でコミットしてしまう
  4. この「間違って main で作ってしまったコミット」を
    feature/new-ui ブランチに移動 させる

最終的には下記の状態作成してください。

  • main：2つ目のコミットは消えている
  • feature/new-ui：そのコミットが存在する

2-3. チェック方法

  • git log --oneline を main と feature/new-ui で比較し、

    • main：最初のコミットだけ
    • feature/new-ui：最初のコミット＋「新UI」コミット
      になっているか確認。

問題3：stash を使って緊急対応に切り替える

3-1. 状況

feature/report ブランチで作業中に、
「今すぐ main でホットフィックスを入れて！」と言われました。

今の変更はまだコミットしたくない状態です。

3-2. 目標

  1. practice03 を作成し、feature/report ブランチを用意
  2. report.txt に何行か任意のコードを書いて、未コミットの変更を作っておく
  3. 未コミットの変更を一時退避 して、main に切り替える
  4. main で hotfix.txt を作成し、ホットフィックスコミットを1つ作る
  5. 再び feature/report に戻り、退避していた変更を元に戻す

3-3. チェック方法

  • feature/report ブランチに戻ったとき、report.txt の変更がちゃんと残っていること
  • main には hotfix.txt に関するコミットだけが増えていること

問題4：自分でコンフリクトを起こして、手で解決してみる

4-1. 状況

main と feature/conflict-demo の両方で同じ行を編集してしまい、
merge 時にコンフリクトが発生する状況を わざと再現 します。

4-2. 目標

  1. practice04 でリポジトリを作成
  2. main で conflict.txt を作成し、1行だけ書いてコミット
  3. feature/conflict-demo ブランチを作って切り替え、同じ行を書き換えてコミット
  4. main に戻り、同じファイルの同じ行を別の内容に変更してコミット
  5. main で git merge feature/conflict-demo を実行し、コンフリクトを起こす
  6. コンフリクトを手で解消し、マージを完了させる

4-3. チェック方法

  • git status で「コンフリクトなし」になっている
  • git log --oneline --graph でマージコミットができている
  • conflict.txt の内容が、自分の意図通りの最終形になっている

問題5：わざと「やらかし」て reflog で復旧してみる

5-1. 状況

Git トラブル対応クイズでも出てきた git reflog を、
実際に使って復旧する 体験をします。

5-2. 目標

  1. practice05 でリポジトリを作成
  2. notes.txt を作り、3回くらい小さなコミットを積む
  3. HEAD を過去に戻すために、わざと git reset --hard HEAD~2 を実行してみる
  4. 「あ、戻しすぎた！」という前提で、git reflog から元のコミットハッシュを探し、
    reset 前の状態まで戻す

5-3. チェック方法

  • 最終的に、notes.txt の内容・コミット数が reset 前と同じになっている
  • git log --oneline で 3 つのコミットが存在している

3. 解答例（ここから先はネタバレ）

ここから先は解答例です（自力で試したい人はここで一度閉じてください）。

ここから先は、上記の問題に対する一例としての解答例です。
自力で試してから読むことをおすすめします。

問題1の解答例

mkdir practice01
cd practice01

git init
echo "Hello Git" > hello.txt
git add hello.txt
git commit -m "feat: add hello.txt"

git switch -c feature/add-second-line
echo "Second line" >> hello.txt
git add hello.txt
git commit -m "feat: add second line"

git switch main
git merge feature/add-second-line

問題2の解答例

cd .. # git-practice ディレクトリに戻る
mkdir practice02
cd practice02

git init
echo "base" > app.txt
git add app.txt
git commit -m "chore: base app"

# 本当は feature/new-ui にいるべきなのに、わざと main でコミット
echo "new ui code" >> app.txt
git add app.txt
git commit -m "feat: add new ui"

# 今の HEAD を別ブランチに移したい
git switch -c feature/new-ui    # 間違ったコミットごとブランチを切るイメージでもOK

# main を1つ前のコミットに戻す
git switch main
git reset --hard HEAD~1

別解として、main → feature/new-ui へ cherry-pick してから main を reset する方法もあります。

問題3の解答例

cd .. # git-practice ディレクトリに戻る
mkdir practice03
cd practice03

git init
echo "base" > report.txt
git add report.txt
git commit -m "chore: base report"

git switch -c feature/report
echo "working in progress" >> report.txt   # 未コミット状態を作る

# ここから stash を使う
git stash push -m "wip: report"
git switch main

echo "urgent bug fix" > hotfix.txt
git add hotfix.txt
git commit -m "fix: urgent hotfix"

git switch feature/report
git stash apply   # or git stash pop

問題4の解答例

cd .. # git-practice ディレクトリに戻る
mkdir practice04
cd practice04

git init
echo "original line" > conflict.txt
git add conflict.txt
git commit -m "chore: add conflict.txt"

git switch -c feature/conflict-demo
echo "feature branch line" > conflict.txt
git add conflict.txt
git commit -m "feat: change line in feature"

git switch main
echo "main branch line" > conflict.txt
git add conflict.txt
git commit -m "feat: change line in main"

# コンフリクトを起こす
git merge feature/conflict-demo
# ここで conflict.txt に <<<<<<< / ======= / >>>>>>> が入るので、
# 好きな内容に手で編集して保存

git add conflict.txt
git commit   # マージコミットを確定

問題5の解答例

cd .. # git-practice ディレクトリに戻る
mkdir practice05
cd practice05

git init
echo "line1" > notes.txt
git add notes.txt
git commit -m "add line1"

echo "line2" >> notes.txt
git add notes.txt
git commit -m "add line2"

echo "line3" >> notes.txt
git add notes.txt
git commit -m "add line3"

# わざとやらかす
git reset --hard HEAD~2   # 一気に2個前に戻す

# reflog で元のコミットを探す
git reflog
# reset 前のコミットハッシュ（例: abc1234）をメモして…

git reset --hard <そのハッシュ>

4. まとめ

  • 今回の実技テストは、あえて「やらかしてから直す」流れを体験する構成にしました。
    本番リポジトリでは怖くて試しにくい操作も、練習環境なら安心して壊せます。
  • branch や stash、merge コンフリクト、reflog による復旧など、
    「もし事故ったらどう戻すか？」をセットで考えるクセ がつくと、実務での心理的安全性がかなり上がります。
  • ここで紹介した手順はあくまで一例なので、ぜひ自分なりのコマンドや流れも試してみてください。
    「別解を探すこと」自体が、Git を深く理解する近道になります。
  • 慣れてきたら、実際のプロジェクトでも「危険そうな操作の前にバックアップブランチを切る」「reflog で戻せるか意識する」など、
    今回の練習で学んだことを少しずつ取り入れてみてください。

これで Git 実技テスト編 はおしまいです。お疲れさまでした！ 🎉

Discussion