おはようございます、YASUです。
本業の休憩中、暇な時間ができたので、AIに問題を作ってもらってGitの理解度チェックをしてみました。ただ問題を解くだけでなく、間違えた部分を掘り下げて解説してもらったところ、以前ハマった箇所の理解がさらに深まったので、今日はその一部をシェアします。
結論
クイズ形式で自分の理解度を確認すると、「分かったつもり」になっていた部分が具体的に浮き彫りになります。特に、実際に手を動かして経験した内容ほど記憶に残りやすく、逆にまだ体験していない部分は同じ問題を繰り返し間違える、という傾向がはっきり見えました。
まずは基本の5問、これは安定して解けた
ステージングの状態、--amendとrevertの違い、git diffの見方、コンフリクト解消時の挙動など、これまで実際に手を動かしてきた内容は5問全問正解でした。特に--amendは、以前実際に違うコミットを誤って書き換えてしまった経験があるので、体で覚えている感覚がそのまま出た形です。
意外とつまずいた、init.defaultBranch の効果範囲
「init.defaultBranchの設定を変更した場合、その効果が及ぶ範囲はどれか」という問題で、うっかり間違えてしまいました。改めて解説してもらったところ、こんな例えが腑に落ちました。
タイムマシンで例えると
① git init(この時点ではmasterがデフォルトのまま)
↓
② init.defaultBranch main を設定(この時、初めて「今後はmainにして」と決めた)
↓
③ git commit(実際にブランチが確定する瞬間)
①の時点では、まだ「今後mainにする」というルール自体が存在していませんでした。だから③でコミットした時、①の時点でのルール(何もしなければmaster)がそのまま適用されてしまう、という理屈です。「タイムマシンで過去は変えられないけど、未来の行動は変えられる」というイメージで捉えると、一気に納得できました。
実務判断を問う問題も、あわせて出してもらった
単なる用語の暗記だけでなく、「こういう状況なら、どう対応するのが適切か」という実務寄りの問題も出してもらいました。特に印象に残ったのがこちらです。
すでにGitHubにpush済みの自分のコミットのメッセージに誤字を見つけた。取るべき対応として最も無難なのはどれか。
ここで思わず--amendで直接書き換える方を選んでしまったのですが、正解は「誤字を直す新しいコミットを追加する」でした。理由は、すでにpushしてチームで共有されているコミットを書き換えると、他のメンバーとの間で履歴の食い違いが生まれてしまうからです。
--amend自体の使い方は理解していたつもりでしたが、「push前か後か」という条件によって、使っていい場面と避けるべき場面が変わる、という判断軸はまだ整理しきれていなかったようです。
慣れてきた頃こそ危ない、という気づき
一連の振り返りをしていて、ふと「慣れてきたら逆にやらかしそうだな」と感じました。最初は慎重に確認していたことも、操作に慣れるにつれて省略されがちになります。実務では、個人の注意力だけに頼らず、ブランチ保護ルールやレビュー必須設定といった「仕組み」でカバーするのが一般的、というのも今回あわせて教えてもらいました。
まとめ
- 実際に手を動かして経験した内容は、クイズでも安定して正解できる
init.defaultBranchは、設定した後に新しく作るリポジトリにしか効果が及ばない--amendは、pushする前の自分だけのコミットに使うのが原則。push後は新しい修正コミットを積むのが無難- 慣れてきた頃こそ、確認を省略しがちになるので要注意
自分で問題を作るより、AIに出してもらって解く方が、思わぬ弱点に気づきやすいと感じた一日でした。それでは、また明日!

コメント