そこで、横から失礼ながら、入門編だけちょっと注釈をつけさせてもらうことにします。わからないヒトのお役に立てれば。
履歴を管理するリポジトリ
リポジトリとは、ファイルやディレクトリの状態を記録する場所です。保存された状態は、内容の変更履歴として格納されています。Git ではひとつのディレクトリ（とそれ以下。あとで出てくるワークツリーのこと。）を管理下に置きます。そのディレクトリの内容のスナップショットがひとつの「状態」としてリポジトリに記録される。その「状態」のつらなりが履歴です。
変更を記録するコミット
コミットを実行すると、リポジトリの内では、前回コミットした時の状態から現在の状態までの差分を記録したコミット(またはリビジョン)と呼ばれるものが作成されますこれは Git の説明としては標準的でないかな…Git ではコミットは差分ではなく、そのときのインデックス（≒ワークツリー）の内容そのもの。コミットを実行する時点でのインデックスの内容が、ひとつのコミットとしてリポジトリに入り、それが（上で書いた）「ひとつの記録された状態」になります。(*1)
（コミットを差分だと理解すると、後で出てくるマージやチェリーピックは分かりやすいんだけど、Git の実装とは離れているので、インデックスやコミットそのものが具体的にイメージしにくくなるのが難しいところ。）
(*1) Git の開発責任者の濱野純氏の著書「入門 Git」2.1節〜2.2節に詳しい。コミットと差分の関係は、p14に以下のように説明されています：
コミットオブジェクトが記録しているツリーオブジェクトは、プロジェクトのコミット時点での状態ですが、このツリーと、1つ前の状態を記録したコミットオブジェクトが記録しているツリーとの間の差分は、このコミットが導入した変更である、と考えることができます。［中略］この差分を計算して、変更点を調査することが可能となるのです。ワークツリーとインデックス
Gitでは、コミットを実行した時にワークツリーから直接リポジトリ内に状態を記録するのでなく、その間に設けられているインデックスの設定された状態を記録するようになっています。そのため、コミットでファイルの状態を記録するためには、まずインデックスにファイルを登録する必要があります。「インデックスの設定された状態」ではなく、「インデックスに設定された状態」かな。誤植なら直してほしい…
インデックスには、ワークツリーそのままが入れられると思ったほうが分かりやすい。てか Git では実際そうなってる。そしてインデックスの内容が、そのままコミットになる。だから、ファイルを修正しても、インデックスに入れなければ、コミットには入らない。
ファイルやディレクトリが「Git の管理下にある」とは、インデックスに入ってるという意味です。図では CSS ファイルがインデックスに入ってませんが、この例なら入ってるでしょう。そして、html ファイルを修正したからインデックスに入れた、css ファイルは修正していないので以前の状態の css ファイルがインデックスにある、それがコミットされる。
（コミットが差分であると考えるなら、こう理解するといいかも：コミットすると、直前のコミットが表わす状態と、現在のインデックスの内容との差分が、新たにコミットとしてリポジトリに入る。）
以降、リポジトリの共有は概念的な説明なので分かりやすいと思います。変更履歴の統合のところは、ブランチを説明してからじゃないと説明が難しいところをうまく説明しているなぁと感心しました。
これでもまだどうも分からんという人には、拙著「わかる Git」を読んでいただきたいと宣伝するなど (^^;;。有料で、「サルでもわかる Git 入門」よりは長いし、かわいいイラストもないけれど、分かるように丁寧に噛みくだいて説明しているつもりです。上の説明のあたりは試し読みもできますので、気に入ったら是非。
