ほとんどの人がgitを学ぶのは必要に迫られてからだよね。「ただコードを書きたいだけで、周辺のことは気にしない」って言ってる人もいるし。JIT学習は実際のアプリケーションに役立つスキルを身につけるのに良い方法だけど、bisectやgitオブジェクト、gitログなどを学ぶためのJITプルはないんだよね。これらは、ドキュメントを読むための時間を取るか、コースで教わることでしか学べないと思う。だから、gitを教えることの重要性を主張するのはいい考えだと思う。多くの人が自分からその取り組みをしない可能性が高いし、gitが得意になることのメリットは明らかだからね。

これは厳しい感じがするな。エンジニアは、もっと重要だと言えることを学ぶための無限のリストを抱えてるし、ほとんど出てこない変なエッジケースを理解する価値があるとは限らないからね（Gitの使いづらくて迷路のようなUXについては何も言わないけど）。

ほとんどの人がツールを正しく使えてないなら、それは彼らのせいじゃなくてツールのせいだよ。Gitは前のものよりはマシだし、やってることでは一番かもしれないけど、それが良いってわけじゃない。 - インターフェースが直感的じゃない。 - 専門用語が多すぎる。 - 機能の発見が難しい。 - 一度問題が起きると、回復するのが難しいことが多い。もしGitに不慣れでその状況に陥ったなら、抜け出すのも難しいってことだよ。これらの問題の多くはGitがコマンドラインインターフェースだからだけど、一般的なアンドゥがないとか変な名前が多いのは単にデザインが悪いからだと思う。そろそろ再挑戦して、もっと良いバージョン管理ツールを作るべきだと思うけど、Gitがあまりにも根付いているのかもしれないね。

そうそう、基本を超えると、GitはエディタやIDEと同じくらいコード編集ツールになるよね。

それぞれのツールは聞いたことあるけど、実際に使ったことはないな。良いコミットメッセージを書こうとして、変更を小さくて明確で理解しやすい形でステージするようにしてるけど、それぐらいかな。でも、Gitの周りの高度なツールはちょっと怖いよね、正直。

あなたのワークフローはFOSSプロジェクトには合ってるけど、プロのチームではPRが作業の単位になることが多いよ。PRはCI/CDパイプラインをトリガーするし、チケットにマッピングされる。意味のあるコミットは、スカッシュマージで共有のdev/mainブランチに行く。PRのためにこういう風にコミットをステージしたこともあるけど、レビューしやすくするためだね。通常は別のPRに分けたいけど、意味のない3つのMRのパイプラインができるなら、1つのMRのために履歴を書き換えるのもアリだと思う。自分のフィーチャーブランチのコミット履歴は自分のためのもので、他の人のためではないと思ってる。履歴を書き換えるのは、PRの説明やタスクの分解がちゃんとできていれば必要ないはずだし、どうせコミットはスカッシュされるからね。それに「MRコメントを修正する」コミットも含まれるし。あなたのワークフローがチームやツール、プロセスに合うなら、それを取り入れるのは全然構わないよ。ただ、あなたのやり方が唯一の正しいやり方じゃないことを考慮してほしい。あなたの好みも大事だけど、他の人の好みも同じくらい大事だから。私が本当に気になるのは絶対主義。「私のやり方か、さもなくば道を外れろ」っていうのはね。あなたの書き込みを見て、過去にいた特に嫌な同僚を思い出したよ。あなたがその人じゃないか確認するために、コメント履歴をざっと見たけど…過度な堅苦しさは魅力的じゃないよね。とはいえ、私はGitのツリー構造の基本を学ぶために1時間か3時間もかけられないYoEが多すぎる人たちには常にイライラしてる。彼らはGUIの杖に頼りすぎて、何か問題が起きたら修正できないんだ。水を飲ませようとしても、資料を送って質問に答えるって言っても、全然飲まない。意図的な無知は頑固さよりもずっとイライラするよ。彼らがbisectとcherry-pickの違いを覚えているとは期待しないけど、Claudeが必要なサブコマンドを英語で説明すれば教えてくれるからね。でも、基礎的なデータ構造を理解していなければ、それすらできないんだ。

「ほとんどのCSプログラムは適切なバージョン管理を教えていない」ってのは単なる間違いだよ。イギリスでは、最初の週にバージョン管理を学んで、その後はコース全体を通してすべての作業をバージョン管理で提出するんだ。アメリカの学校でバージョン管理を使わないなんて信じられないよ。全然意味がわからない。

2026年の学生がLLMを使うことに対して特に励ましは必要ないと思うけど、LLM企業が学生プランを安く提供しないのは変だよね。