Version Control with Git ch4 Basic Git Concepts (1/2)
Basic Concepts
- 前章で生じたであろう疑問
- Gitはファイル全体を毎コミット保存するの?
- .gitディレクトリの役目は?
- なぜコミットIDはわけがわからないの?書き留めておくべき?
- 他のモダンなVCSが提供しているものと同じ機能は備えている
- しかしそれらとは根本的に異なる
- 本章の内容
Repositories
- リポジトリとは
- コンフィグファイル
- Gitが維持する2つのデータ構造
Git Object Types
- Object StoreはGitリポジトリの心臓部
- プロジェクトのバージョンやブランチを復元するのに必要な情報全てを含む
- 元のデータファイル
- ログメッセージ
- author情報
- 日付
- etc.
- オブジェクトは4種類
- ディスクと帯域の効率のためにpack filesとして圧縮保存される
Index
- リポジトリ全体のディレクトリ構造を表現する、一時的で動的なバイナリファイル
git add
のステージング領域とか- マージで重要な役割を担う
- 同時に同じファイルの複数のバージョンを管理し検査し操作できる
Content-Addressable Names
Globally Unique Identifiers
- ファイルがどこにあろうが同じファイル内容ならば同じハッシュ値というのが重要
- たとえ別のマシン上でも
- ファイル同一性比較の際、SHA1ハッシュ値を比較するだけでよいのが強力
- 任意のファイルサイズ
- インターネット越しでも
Git Tracks Content
- Gitのコンテンツ追跡は、他のVCSとは2つの点で根本的に異なる
Pathname Versus Content
- Gitはファイルの内容とファイル名とを別々に管理している
- 元のディレクトリ構造よりも効率的な内部表現でデータを格納している
Pack Files
- 「全バージョン全ファイルをオブジェクトストアに格納しているのは非効率なのでは?」
- 結論NO
- pack filesにいい感じに差分圧縮している
- 【所感】Different Layers, Different Abstractions (APoSD)
Object Store Pictures
- 【補】
git cat-file
サブコマンドでオブジェクトの中身を見れる
git cat-file -p master^{tree}
040000 tree 90242d36854889cac7893116118dc97b0a0e947f rabbit-house 100644 blob 200efce75e8f04b16ac365eb554b38e55573488e syaro
- ファイルの中身がblobとして格納される
- 複数のtreeでblob共有
- rize
- syaro
- treeはtreeまたはblobを指す
- 指す内容が変わればハッシュ値も変わる
- commitの内容
- author、committer等
- tree
- 親commit
- tagは
refs/tags/v1.0
のようなファイル名 - ほかは
objects/b5/1f1cd76f543ce81445a290fb0e4fe37f86c93f
のようなファイル名 - よく見るコミットグラフとは矢印の向きが逆であることに留意する
- よく見るやつ: コミットの順序
- 上で示した図: 参照の向き
英語
- gibberish
- ちんぷんかんぷんな
- transitory
- 一時的な
- corollary
- 帰着
- exposition
- 詳細な解説