これらのトピックに関する他のいくつかの優れたリファレンス:
インデックスをチェックポイントとして使用します。
失敗する可能性のある変更を加えようとしているとき—概念的に要求するリファクタリングや変更など、フォロースルーできるかどうか、またはそれが良いアイデアかどうかわからないような方向性を探りたいとき表現タイプ—作業をインデックスにチェックポイントします。これが最後のコミット以降に行った最初の変更である場合は、ローカルリポジトリをチェックポイントとして使用できますが、多くの場合、一連の小さな手順として実装している1つの概念的な変更があります。各ステップの後にチェックポイントを設定したいのですが、テスト済みの機能するコードに戻るまでコミットを保存します。
ノート:
ワークスペースは、(ソース)あなたが見ることのファイルや編集のディレクトリツリーです。
インデックスは、単一、大規模な、バイナリファイルである<baseOfRepo>/.git/index
現在のすべてのブランチ内のファイル、その一覧表示し、SHA1のチェックサム、タイムスタンプとファイル名を-それはそれでファイルのコピーと別のディレクトリではありません。
ローカルレポジトリは、隠しディレクトリである(.git
を含む)objects
の圧縮「ブロブ」ファイルとしてリポジトリ内のすべてのファイルのすべてのバージョン(ローカルブランチ及びリモートブランチのコピー)を含むディレクトリ。
上の画像に示されている4つの「ディスク」をrepoファイルの個別のコピーと考えないでください。
これらは基本的にGitコミットの名前付き参照です。refには、主にタグとヘッドの2つのタイプがあります。
- タグは、v2.6.29など、履歴の特定のポイントをマークする固定参照です。
- それどころか、ヘッドは常にプロジェクト開発の現在の位置を反映するように移動されます。
(注:Timo Huovinen によってコメントされたように、これらの矢印はコミットが指すものではなく、ワークフローの順序であり、基本的1 -> 2 -> 3 -> 4
に1
は最初のコミットと4
最後の矢印が矢印であることを示しています)
これで、プロジェクトで何が起こっているかがわかりました。
しかし、ここで何が起こっているかを知るために、現在、HEADと呼ばれる特別な参照があります。それは2つの主要な目的を果たします:
- チェックアウト時にファイルを取得するコミットをGitに指示します。
- コミットするときに新しいコミットをどこに置くかをGitに指示します。
実行git checkout ref
するHEAD
と、指定した参照をポイントし、そこからファイルを抽出します。実行するgit commit
と、新しいcommitオブジェクトが作成され、currentの子になりますHEAD
。通常HEAD
は頭の1つを指すので、すべてうまくいきます。
HEAD
現在のブランチの先端でのコミットです。ブランチをチェックアウトした直後、つまり変更されたファイルがない場合、その内容は作業ツリーと一致します。何かを変更するとすぐに一致しなくなります。