
Gitは業務で毎日触っているのに、コマンドを覚えているだけで「なぜそうするのか」まで説明できない。
または、ソースツリーなどのGUIツールを使うことで、コマンドラインでのGitの操作が怪しくなっていませんか。
私自身がまさにそうでした。エンジニアとして5年以上働いてきて、Gitは理解しているつもりでも、いざ「このコマンドって何をしているの?」と聞かれると、正直あやふやなまま答えていた気がします。
この記事では、私がClaude Codeを使ってGitを学び直したときに、実際にどう使い、どこで詰まり、結果として何が変わったのかを、体験談として書いていきます。
よくあるノウハウ集というよりは、あくまで私の実体験ベースの話です。
なぜ今さらClaude codeでGitを学び直そうと思ったのか?
きっかけは、ソースツリーのようなGUIツールに頼りきっていることへの不安でした。
ボタンをクリックすれば大抵のことはできてしまうので、コマンドラインでの操作から少しずつ離れていったんです。
ただ、いざチームの別のメンバーがコマンドで作業している画面を見たときに、「あれ、これ何のコマンドだっけ」と思う瞬間が何度かありました。
動かせるけれど、説明できない。この状態にちょっとした危機感を覚えたのが正直なところです。
そこで、普段の開発でも使っているClaude Codeに、Gitの疑問をそのままぶつけてみることにしました。
Gitの操作からも離れたことも学び直すきっかけに
また、私はプログラマーから離れて、設計などの仕事がメインとなり、SEとして2年近くすぎた頃に、
「あれ?そろそろGitの操作が怪しくなってきたぞ??」
「git pullやgit stashとかの操作ってどうやってコマンド打つんだっけ?オプションも忘れてきたな…」
こんな感じで、コマンドを叩かなくなってくると、人間は忘れるものです。
プログラムを書いていた頃は、あれだけGitの操作をしていたのにもう忘れているなんて!!
急にこの先のエンジニア人生が怖くなり、Claude codeを使ってGitを学ぼうと思ったのもきっかけです。
まずは、私がどんなGit操作に不安を抱えていたのかを紹介しながら、実際にClaude codeでGitを学び直した流れを紹介していいます。
Claude codeでGitを勉強①:おまじないだった git push -u origin ブランチ名
経験談として、いちばん印象に残っているのがこれです。
おまじないのように git push -u origin ブランチ名 と打っていたけれど、そもそもこの -u って何のためにあるのか?originってなに?
2回目以降は git push だけで済むのはなぜなのか?
もし -u を付け忘れてプッシュしたら、やり直さないとダメなのか?
昔から「おまじない」感覚で打っていたコマンドでした。


「コマンドの手順」ではなく「Gitが裏で何をしているのか」を理解できたことで、おまじないからの脱却ができました。
Claude codeで実際にやりとりした内容
まずはclaude codeに下記のようにフラットに聞きました。
git push -u origin feature-branch の -u って結局何をしているの?毎回指定しないとダメ?コマンドの意味や -u(–set-upstream)オプションの具体的な役割に対する素朴な疑問を投げてみたって感じです。
やりとりしていくなかで、下記のようなことも聞いてます。
upstream(追跡ブランチ)を設定すると何が嬉しいの?2回目以降の git push や git pull がどう変わる?結果的にClaude codeによって理解できたことは以下です。
-u はローカルブランチとリモートブランチ(origin/ブランチ名)の間に追跡関係(Upstream)を設定するフラグであることを理解した
初回に -u を付けて push しておけば、次回以降はターゲットを指定せず git push や git pull だけで意図通りに動くようになり、入力の手間と指定ミスのリスクが減る
Claude codeでGitを勉強②:git stash系のコマンドの理解があまりない
次に詰まっていたのがスタッシュ周りです。
git stashは、GUIのソースツリーでだいたい操作していたので、コマンドでしっかりと学んだことはなく、なんとなく知っているぐらいでした。


Claude Codeとの対話で、git stash list で一覧を確認する方法や、メッセージ付きで退避する習慣の重要性を理解できました。
さらに、スタッシュを戻す際の git stash apply と pop の違い、つまり履歴を残すか消すかの違いを整理できたことで、作業の退避と復元を怖がらずにコントロールできるようになったのは大きな変化だったと思います。
Claude codeでgit stash系についてやりとりした内容
やりとりした内容はこんな感じです。
git stash すると未追跡(新規作成)のファイルも消えちゃうの?どうやって一緒に退避する?stash の一覧でどれが何の作業かわからなくなる。メッセージ付きで退避するには?git stash pop と git stash apply って何が違う?間違えて消したくないんだけど...誤って git stash drop や clear で消しちゃった場合、復元する方法ってある?Claude codeを使って割とgit stash系のコマンドについて理解を深めました。
git stash系のコマンドは、ソースコードを退避する時によく使うかと思うので、この際に丸っと学び直せたのが良かったです。
git stash save “メッセージ” や git stash push -m “メッセージ” を使うことで、複数のスタックがあっても git stash list で一目で作業内容がわかることの理解が深まった
基本は git stash pop で適用&削除しつつ、別のブランチにも同じ変更を適用したい時や慎重に確認したい時は git stash apply を使うなど、目的に応じたことが理解できた
万が一 stash を誤削除した場合でも、コミットハブ(git reflog)からたどって復元できる知識がついた
Claude codeでGitを勉強③:squash and mergeってなんだっけ?
もうひとつ、モヤモヤしていたのがSquash Mergeまわりの挙動でした。
GitHub上で「Squash and merge」を使ってPRをマージした際、リモートのメインブランチには1つのコミットとしてまとめられる仕様になっています。


squash and mergeについても、プログラムを書かなくなると仕組みとかを忘れてしまったので、実際に学び直すことでいいきっかけとなりました。
Claude codeでGitを学び直して良かったこと
ここまで書いてきましたが、ソースツリーのようなGUIツール自体が悪いわけではありません。視覚的に差分やブランチの状態を把握できるのは、やはり便利です。
ただ、GUIだけに頼っていると、裏で何が起きているのかを説明できないまま作業を進めてしまう地獄にハマりがちだと感じます。
コマンドの意味を理解した上でGUIを使うのと、なんとなくボタンを押しているだけなのとでは、トラブルが起きたときの対応力が大きく変わってくるはずです。
Claude Codeを使って学び直してよかったのは、単に「答えを教えてもらった」だけでなく、なぜそうなるのかを自分の言葉で説明できるようになったことでした。
Claude codeでGitを学ぶのもいいがやはり体系的に知識をつけることが大事
Claude Codeとの対話で疑問をひとつひとつ解消していくやり方は、たしかに効果的でした。
ただ、その場しのぎの理解を積み重ねるだけでは、知識が点のまま散らばってしまう気がします。
ブランチ戦略やGitの内部構造など、体系立てて学べる書籍や公式ドキュメントに触れることで、点と点がつながり、応用の効く理解に変わっていくのだと思います。
このブログでは、Gitのおすすめ本についても紹介しているので、勉強するのにぴったりの本を下記の記事から選んでみてください。

まとめ
もし普段からGitを何となく使っている自覚があるなら、まずは自分がおまじないのように打っているコマンドを1つ思い浮かべてみてください。
git push -u や git stash、Squash Mergeなど、意外と身近なところに理解できていない部分が隠れているものです。
その1つをClaude Codeに素直に聞いてみるところから始めてみてはいかがでしょうか?




コメント