専門用語少なめ！GIT入門-コミットとステージング【基礎知識シリーズ】
概要
皆さんこんにちは、SoLA2です。
基礎知識シリーズ第5回目です。今回も引き続きGit入門ということで、コミットについて解説していきます。さあみなさんも結果にコミットしていきましょう。
コミットとは
あのRIZAPのCMでおなじみのフレーズをきっかけに「コミット」という言葉を知った方も多いかも知れません。Gitの世界で「コミット」とは、バージョン毎の記録を意味します。なので「結果にコミットする」をGit風に言うならば、「筋トレをして新しいバージョンの体を作りましょう」でしょうか（笑
コミットの中身
Gitでコミットはバージョン毎の記録であることは前述しました。では、何が記録されているのでしょうか。大きく分けて3つの要素が記録されています。
- 変更情報（いつ、だれが、何を変更したか）
- 備考（変更者のメッセージ）
- システム管理用情報（リビジョン番号と、前バージョンのリビジョン番号）
コミットというとなんだか大それた感じがしますが、中身は割とシンプルですね。リビジョン番号というのは、コミット版のマイナンバーみたいなものです。実際には番号ではありませんが、すべてのコミットの中でひとつしか存在しないという点では同じです。
余談ですが、リビジョン番号は1から始まる連番ではなく、コミット内容のハッシュ値で管理されています。ただ一意の番号を振りたいだけなら連番にすればいいところ、なぜこのような面倒な仕様にしたのか。実はこれにはわけがあります。
前回の記事でリポジトリにはローカルリポジトリとグローバルリポジトリがあることを説明したと思います。バージョン管理を複数のリポジトリで行うことを分散型と呼びますが、分散型のようにリポジトリが複数存在すると困ることがあるのです。
リビジョン番号をそれぞれのローカルリポジトリで連番にしてしまうと、変更内容をグローバルリポジトリに反映する時に、リビジョン番号が重複してしまう可能性が出てくるのです。そのためこのような面倒な文字の羅列でリビジョン番号を一意にしています。
コミットするまでの流れ
実はGitの場合はファイル変更してからコミットするまでに、もう一段階手順が存在します。省略することも可能ですが、便利ですので積極的に使っていきましょう。
インデックスへの追加
実は、バージョン管理下にあるファイルを変更してもそれを直ちにコミット対象のファイルとして認識することはありません。変更したファイルの中からコミット対象となるファイルを選択する必要があります。この選択する行為をインデックスに追加（ステージング状態にする）と言います。
バージョン管理をしたことが無いと、なぜこのような冗長的な行為をする必要があるのかピンと来ない方もいるかも知れません。実はバージョン管理のしやすさを考慮すると、この中間地点が非常に便利（というより必須）に感じるようになります。
そもそもバージョン管理をする理由は、バックアップを取っておいて必要なときにすばやく前のバージョンへ戻すためでした。であれば、バージョン毎に「どのタイミングで取得したバックアップなのか」は明確であるべきで、更に言うと「戻りたいタイミングでバックアップをとっておく」べきなのです。
バージョンとはコミットのことでしたね？つまり「Aという修正」と「Bという修正」をして、それらを一括でコミットしてしまうと、戻れる地点が「AとBを修正する前」だけになってしまいます。AとBに関連性があればそれでいいのですが、全く別物だった場合は都合が悪いですね。
そこで、一旦「Aという修正」の該当箇所のみをインデックスに追加してからコミットし、その後「Bという修正」の該当箇所をインデックスに追加してコミットすることで、戻れる地点を「AとBを修正する前」と「Bを修正する前」に増やすことができるようになります。
コミットの粒度に関しては多すぎても少なすぎても良くありません。塩梅についてはある程度の目安はあるにしても、経験を積んで理解するしかありません。いずれにしろ確実に言えることは、インデックス（ステージング）という概念はGitにおいて非常に重要であるということです。
まとめ
今回はGitのコミットについて学びました。これで一人でバージョン管理する分には必要な知識が揃いました。次回は実際にファイルのバージョン管理をしていく流れをスクリーンショットを交えて紹介していきます。
ではまた。
