Kindle ストアにもきました

パブーの外部ストア連携機能を使ってアマゾン Kindle ストアにも置いてもらいました。



ランキングをちょっと見てたけど、そこそこ買ってくれている人がいるみたい。ありがたいことです。

パブーのほうはこちら → 「わかる Git」

「サルでもわかるGit入門」がわからないヒトのために

「サルでもわかるGit入門」が人気のようです。ツイッターで見ていると、よさそうと言う人とやっぱり分からないという人がいる。私も見てみたが、うん、分からないかもな、と思うところがあった。

そこで、横から失礼ながら、入門編だけちょっと注釈をつけさせてもらうことにします。わからないヒトのお役に立てれば。

履歴を管理するリポジトリ

リポジトリとは、ファイルやディレクトリの状態を記録する場所です。保存された状態は、内容の変更履歴として格納されています。

Git ではひとつのディレクトリ（とそれ以下。あとで出てくるワークツリーのこと。）を管理下に置きます。そのディレクトリの内容のスナップショットがひとつの「状態」としてリポジトリに記録される。その「状態」のつらなりが履歴です。

変更を記録するコミット

コミットを実行すると、リポジトリの内では、前回コミットした時の状態から現在の状態までの差分を記録したコミット(またはリビジョン)と呼ばれるものが作成されます

これは Git の説明としては標準的でないかな…Git ではコミットは差分ではなく、そのときのインデックス（≒ワークツリー）の内容そのもの。コミットを実行する時点でのインデックスの内容が、ひとつのコミットとしてリポジトリに入り、それが（上で書いた）「ひとつの記録された状態」になります。(*1)

（コミットを差分だと理解すると、後で出てくるマージやチェリーピックは分かりやすいんだけど、Git の実装とは離れているので、インデックスやコミットそのものが具体的にイメージしにくくなるのが難しいところ。）

(*1) Git の開発責任者の濱野純氏の著書「入門 Git」2.1節〜2.2節に詳しい。コミットと差分の関係は、p14に以下のように説明されています：

コミットオブジェクトが記録しているツリーオブジェクトは、プロジェクトのコミット時点での状態ですが、このツリーと、1つ前の状態を記録したコミットオブジェクトが記録しているツリーとの間の差分は、このコミットが導入した変更である、と考えることができます。［中略］この差分を計算して、変更点を調査することが可能となるのです。

ワークツリーとインデックス

Gitでは、コミットを実行した時にワークツリーから直接リポジトリ内に状態を記録するのでなく、その間に設けられているインデックスの設定された状態を記録するようになっています。そのため、コミットでファイルの状態を記録するためには、まずインデックスにファイルを登録する必要があります。

「インデックスの設定された状態」ではなく、「インデックスに設定された状態」かな。誤植なら直してほしい…

インデックスには、ワークツリーそのままが入れられると思ったほうが分かりやすい。てか Git では実際そうなってる。そしてインデックスの内容が、そのままコミットになる。だから、ファイルを修正しても、インデックスに入れなければ、コミットには入らない。

ファイルやディレクトリが「Git の管理下にある」とは、インデックスに入ってるという意味です。図では CSS ファイルがインデックスに入ってませんが、この例なら入ってるでしょう。そして、html ファイルを修正したからインデックスに入れた、css ファイルは修正していないので以前の状態の css ファイルがインデックスにある、それがコミットされる。

（コミットが差分であると考えるなら、こう理解するといいかも：コミットすると、直前のコミットが表わす状態と、現在のインデックスの内容との差分が、新たにコミットとしてリポジトリに入る。）

以降、リポジトリの共有は概念的な説明なので分かりやすいと思います。変更履歴の統合のところは、ブランチを説明してからじゃないと説明が難しいところをうまく説明しているなぁと感心しました。

これでもまだどうも分からんという人には、拙著「わかる Git」を読んでいただきたいと宣伝するなど (^^;;。有料で、「サルでもわかる Git 入門」よりは長いし、かわいいイラストもないけれど、分かるように丁寧に噛みくだいて説明しているつもりです。上の説明のあたりは試し読みもできますので、気に入ったら是非。

Git のチュートリアル電子書籍を書きました

自分、今でこそ Git を不安なく使えるけど、最初は自分が何をやってるか全然わからなかった。

いや、このコマンドはこれをするんだ、とは本に書いてある。でも、なんというか、Git が中で何をやってるか、その「気持ち」が分からなかった。だからすぐ「detached HEAD になったぞ」とか言われて、何だそれは、何でそうなったんだ、みたいなことになってた。

一応、本は結構読んだ。「git 入門」を読んで、「Gitによるバージョン管理」も読んで、「Pro Git」の和訳も読んだ。でもそんな状態。（そのあと「Git 入門」も読んだけど、それでも「気持ち」はあまり伝わらなかった。）

それでやってみたのは、Git の気持ちの仮説を立てて、いろいろ試してみること。Git がこう思ってるなら、こうすればこうなるはずだ、と。それで、思いつく限りを試して、外れることがなければ、それが Git の気持ちのはず。

それを繰り返して書いたのが、この本です。

「わかる Git」（パブー）

Git の気持ちがわかる体験をしてもらおうというチュートリアルになってます。多分。

以前の私と同じように、Git に悩んでいる人のために。