MENU

git status の4つの状態と、コミットを間違えて直した話

Terraformの「共通部品化」、モジュールを使ってみたことを説明する画像

おはようございます、YASUです。

前回、本に沿って`zukai_git`フォルダを一から作り直す話を書きましたが、今回はその続き。ファイルの状態管理、コミット履歴の確認、そして最後は「AIと一緒に学習していたら、AI側がやらかした」というオチまで、盛りだくさんの回でした。

目次

結論

Gitの状態(Untracked/Staged/Modified)を実際に手を動かして体験し、`–amend`というコミット修正コマンドの威力と怖さを、身をもって学びました。「対象を勘違いして直前のコミットを書き換えてしまう」という失敗を実際に目撃し、便利なコマンドほど確認を怠ると危険、という教訓を得た回です。

まず、ファイルの4つの状態を体感する

本には、作業ツリーの状態として4つのパターンが紹介されていました。

  • Untracked(未追跡):Gitがまだ存在を認識していない新しいファイル
  • Staged(ステージング済み):`git add`した状態
  • Modified(変更あり):一度コミットしたファイルに、また変更が加わった状態
  • Unmodified(変更なし):コミット内容と今の中身が一致している状態

実際に`index.html`と`activity.html`を使って、この4状態を一通り体験してみました。

git add index.html
git commit -m "fix: index.htmlを追加"
git status  # → activity.htmlがUntrackedとして表示される

git add activity.html
git status  # → Staged(Changes to be committed)に変わる

git commit -m "feat: activity.htmlを追加"

echo "何か追記" >> index.html
git status  # → index.htmlがModifiedとして表示される

言葉で説明されるより、実際に`git status`の表示が切り替わっていくのを見る方が、圧倒的に理解が早かったです。

コミットメッセージのプレフィックスも実践

本のコラムにあった「よいコミットメッセージの書き方」を参考に、`feat:`(新機能)、`fix:`(修正)、`chore:`(雑務)といったプレフィックスを実際に使ってみました。単なるルールとして覚えるより、実際に手を動かしながら使い分けると定着が早い気がします。

git log でコミット履歴を確認

git log

これまで積み重ねたコミットが、新しい順に一覧表示されました。長い履歴は画面に収まりきらず、下に`:`が表示されて一時停止することがありますが、その場合は`q`キーで通常の画面に戻れます(この一時停止機能、地味に最初戸惑うポイントでした)。

本題:–amend で、実際にやらかした話

ここからが今回の本題です。直前のコミットメッセージを直したくなった時に使う`–amend`というコマンドがあります。

git commit --amend -m "新しいメッセージ"

これは「一番最後に作ったコミットの中身を、上書きして直す」というコマンドです。今回、AIと一緒に「古いテスト用コミットのメッセージを直そう」という話になったのですが、実際に`–amend`が書き換えるのは常に「今、一番新しいコミット」です。

ところが、AI側が「今、一番新しいコミットはどれか」を勘違いしていて、本来直したかった古いコミットではなく、全く別の(index.htmlを変更した)最新コミットのメッセージを、意図せず書き換えてしまいました。結果、「index.htmlの変更」なのに「テスト用ファイルを追加」という、中身とズレたメッセージが付いてしまう事態に。

git show 7fb9ea7 --stat

このコマンドで中身を確認したところ、案の定`index.html`が対象になっていることが判明。もう一度`–amend`で、正しいメッセージに直しました。

git commit --amend -m "fix: index.htmlの内容を更新"

この失敗から得られる教訓

幸い、練習用のリポジトリだったので実害はありませんでしたが、これが実務で、しかもすでにpush済みのコミットだったら話は別です。`–amend`は「まだ誰にも共有していない、自分だけのコミット」に対してだけ使うのが原則です。もしpush済みのコミットを書き換えてしまうと、チームメンバーとの間で履歴の食い違いが生まれ、コンフリクトの元になります。

そして何より、「今、一番新しいコミットは何か」を`git log`や`git show`で確認せずに`–amend`を打つのは危険、ということを、AIの失敗を通じて実感しました。便利なコマンドほど、実行前の確認を省略しないことが大事だと再認識した出来事でした。

まとめ

  • 作業ツリーの4状態(Untracked/Staged/Modified/Unmodified)は、実際に`git status`の変化を目で追うのが一番の理解の近道
  • `git log`の履歴表示が長い時は`q`キーで抜けられる
  • `–amend`は「常に一番新しいコミット」を書き換えるコマンド。対象を勘違いすると、意図しないコミットを上書きしてしまう
  • `–amend`はpush前の、自分だけのコミットに使うのが原則

AIと一緒に学習していると、こちらが気づかないミスをAI自身がしてくれることもあり、それはそれで良い学びの機会になるものですね。それでは、また明日!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

目次