はじめに
『Gitによるバージョン管理』を再読しています。昨日読んだところをざっくりと復習してみたいと思います。
主な内容はタイトルのとおりです。HEAD, ORIG_HEAD, FETCH_HEAD, MERGE_HEADについて書きたいと思います。
前準備
前準備として、Gitの概念を紹介します。しかし、詳しい説明ではありませんので、必要に応じて公式のドキュメントを参照していただければと思います。
まず知って欲しいことは、リポジトリとブランチです。リポジトリにはローカルリポジトリとリモートリポジトリがあります。ブランチにはローカルブランチとリモートブランチとリモートトラッキングブランチがあります。リモートトラッキングブランチ以外は特に難しいことはありません。そして、リモートトラッキングブランチも見た目ほど難しいことはありません。多分。
リモートトラッキングブランチだけ少し補足します。これはどこのリポジトリの何のブランチと関連しているかを記録したものだと思います。
例えば、あるローカルリポジトリで$ git remote add <repo-name> <repo-url>というコマンドを実行したときに、リモートトラッキングブランチはrepo-name/masterのように表されます。repo-nameはリモートリポジトリの名前で、ユーザーが指定できます。masterはリモートリポジトリのブランチ名です。
多分、もしローカルリポジトリのブランチがtestであれば、リモートリポジトリのブランチもtestになると思います。
ここではそういう概念があると知っているだけでよいです。この記事ではそれ以上のことを要求しません。もし興味があればこれらの単語で検索すれば、数分で理解できると思います。
次に知ってほしいことは、ワーキングツリーとインデックスです。ワーキングツリーとインデックスとリポジトリ。これら三つは兄弟のような関係です。ここでもそういう概念があると知っているだけでよいです。
感じとしては、ワーキングツリーで作業して、コミットしたい変更だけインデックスに登録して、コミットする。コミットすると、インデックスに登録した変更だけがリポジトリに記録される。そんな感じだと思います。
さて、本題です。Gitではリビジョン番号に連番を使いません。代わりに、ハッシュ値を使います。これは、大勢で開発するために発明されたアイデアです。
例えば、15番のリビジョン番号をAさんとBさんがチェックアウトしたとします。Aさんが作業して、コミットすると、リビジョン番号は16番になります。Bさんも同じです。つまり、リビジョン番号に連番を使うと、コミットをリビジョン番号で特定できないことがあります。この問題を回避するためにハッシュ値を使っているとのことです。
ちょっと複雑かもしれませんが、ここまでで三つの視点がありました。
- リポジトリとブランチ
- ワーキングツリーとインデックスとリポジトリ
- ハッシュ値
そして、今回この記事で紹介するHEAD, ORIG_HEAD, FETCH_HEAD, MERGE_HEADはハッシュ値の別名です。
HEAD
最新のコミットに対するハッシュ値の別名です。
ORIG_HEAD
最新の一つ手前のコミットに対するハッシュ値の別名です。
FETCH_HEAD
$ git clone ...したときのリモートブランチの最新のコミットに対するハッシュ値の別名です。
MERGE_HEAD
$ git checkout master
$ git merge <branch-name>
このようなコマンドを実行して、ローカルブランチ<branch-name>の変更をmasterブランチにマージしたとします。
このときのローカルブランチ<branch-name>の最新のコミットに対するハッシュ値の別名です。
あとがき
私自身Gitの経験が浅いので、誤りに気付きましたら、お手数ですが、編集リクエストやコメントで教えていただけるとありがたいです。