最近Gitを多少理解した。
Gitを理解することは、ソフトウェアの設計について深く考えさせられる体験である。おそらく、SCMになんの関心もない人にとっても、Gitを理解することは有益だ。理解した結果ではなく、理解する過程が有益となる。
Gitを理解した結果は、Gitを理解する過程に比べると、些細なものだ。tarballとパッチによるワークフローの、賢く素早いが面倒な自動化――「そうそう、コンピュータってこういうものなんだよ」と改めて思い出させてくれる。賢く素早いが、面倒。
インターネットが普及し始めてから20年以上が過ぎた。コンピュータによる自動化が容易な分野は、掘り尽くされつつある。今後新しく登場する種類のソフトウェアの多くは、Gitと似た問題を抱えるだろう。
Gitを理解するうえでの困難について書き留めておく。
・用語の混乱と不統一
まず、名詞のcommitと動詞のcommitがある。
名詞のcommitとはなにか。tarballに属性がついたものだ。この属性を使って、Gitはすべての操作を自動化する。動詞のcommitは、名詞のcommitを作成する操作だ。
次に、index。あまりにも一般的な名前のためか、「ステージングエリア」という言い換えがよくなされる。
そしてcheckout。ソースコードを持ってくる操作のように見える名前だが、同時にブランチも操作する。そして、ソースコードを持ってこずにbranchだけを新規作成するときにも、checkoutが使われる。
どれも「あるある」的な混乱と不統一だが、多くの場合、Gitほどの困難を生み出さずに済んでいる。なぜGitではまずいのかというと、
・核となる概念が消去されている
Gitの核は実は簡単で、tarballとパッチ、それだけだ。tarballはソースコードを固めたもの、パッチはソースコード間の差分を集めたもの。なにも難しいことはない。
が、Gitは賢い自動化のために、パッチを直接の操作対象として扱わせない。そのため、名詞のcommit、履歴（≒名詞のcommit間の家系）、branchなどの概念を同時に理解する必要が生じる。
自動化は大なり小なりピタゴラ装置だが、tarballとパッチを自動化するだけで、これほどのピタゴラ装置が生み出される。ソフトウェアの設計について考えるうえで、Gitのケーススタディには大きな意義があるだろう。