読者です 読者をやめる 読者になる 読者になる

SubversionおじさんがGit始めて3日目くらいに知るべきこと

雑記 Git

はじめに

ツールを置き換える行為は苦痛が伴う。
特に初めのうちは良いところより悪いところを見つけようとしてしまいがち。


たとえば空のディレクトリが作れないとか、Subversion なら作業コピーの状態に関わらず update してくれるのに Git の pull は変更が競合するとあきらめちゃうとか。
でも GitHub を中心にこれだけ広まっている Git を避ける理由としては、その程度では弱い。


何かを導入するときはメリットとデメリットをあげて・・・というプロセスを踏むけど、Git を使うメリットは使えば理解できるので、ここでは Git とつき合うために何を知るべきかという話を書く。
(えらそうなことを言っているけど、まだシゴトで使い始めて1ヶ月程度・・・)


何を知るべきか

それは、Git の構造や設計を理解すること。


なぜかと言うと、
「なんでこういう動きになっているんだろう?」
という疑問に対して、だいたいの想像がつくようになるから。


数多くある Git のコマンドの使い方を一つずつ調べるよりもよっぽど役に立つ。

僕が読んだのはこの本。

Gitによるバージョン管理

Gitによるバージョン管理


この本ではシーンに沿ってコマンドを解説している。
ただ、コマンドを追うよりも用語と役割を意識して読むと、理解が深まると思う。
あと、「GIt リポジトリの中身を見る」の章が特に構造を知る上で参考になった。


構造に特化した内容では下の記事も大変参考になる。

見えないチカラ: 【翻訳】Gitをボトムアップから理解する


おさえておきたいところ

上の本や長い解説記事を全部読みたくない人のために、僕が気になったポイントだけおさえておく。


コミットはハッシュで管理される

Subversion ではリビジョン番号が連番でついていたけど、Git ではハッシュが振られる。
これは Git が分散型のバージョン管理システムであるため、この設計になっている。


分散型で複数人の開発者がそれぞれローカルでコミットし、リモートにプッシュされたとすると、連番ではバージョン番号が衝突してしまう。
これを防ぐためにハッシュで管理される。


コミットのつながり

Git masterのみ

Git の解説ではよくこんな図を見かける。
コミットのつながりをイメージ化した図。


コミットとは、プログラマが一度は通るであろう「リスト構造のノード」に似ている。
特徴は「コミットは必ず前のコミットのハッシュを持つ」。


Git branch

ブランチを切るとこうなる。
注目すべきはCの「ブランチを切った箇所」で、DとZが前のハッシュであるCを持っているということ。
ブランチは単に「前のコミットのハッシュとして参照しているコミットが複数ある」というだけ。


Git merge

ブランチがマージされるとこうなる。
マージコミットのFが他と違うのは、EとYのハッシュを持っているということ。
最初の説明で
「コミットは必ず前のコミットのハッシュを持つ」と書いたが、
「コミットは必ず前のコミットのハッシュを1つ以上持つ」となる。


ブランチ・タグはコミットのポインタ

上であげた図を見ての通り、ブランチやタグはどのコミットを見ているかを表す、ポインタみたいなものだ。
動詞としてのコミットの役割は、コミット(こっちは名詞)をつくるのと同時にポインタを動かすということ。


これがわかると、ブランチを消す意味も自ずとわかる。
まずは単純にポインタを消す。
その後、存在意義がなくなったコミットを消す。

Git branch

仮に上の図で feature1 ブランチを削除すると、コミットZはどのブランチからも参照されないことになり、存在意義を失う。
これによりZは削除される。


Git ではマージされていないブランチを削除しようとするとデフォルトで止められる。
これはコミットを失う結果になるから止められるのだ。
マージされているかどうかではない。
同じコミットを指すブランチが複数あれば(上でいえばコミットZを参照する別のブランチがあれば)、feature1ブランチを削除してもコミットが消えないため、Git に止められずに削除できる。


最後に

紹介した本と記事さえ読めば上の解説なんて読まなくていい。
それなのに思わず書いてしまったのは Git の設計に惹かれたから。
シンプルで優れた思想だと思う。


Subversion はそれほど中身のことに知らなくても使えたが(というか TortoiseSVN という素晴らしいツールがすべてをラップしてくれた)、Git では Git の構造や設計をおさえることでより便利に使えると感じる。
僕のように今さらながら Git デビューする人は「Git Subversion 違い」でググるよりも、この素敵な構造や設計を知ってほしいなと思った。


Gitによるバージョン管理

Gitによるバージョン管理

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)