作業をしていると、ここで一度保存したくなることがあります。それは進めている途中で、この地点に戻ってくる価値があると感じるからでしょう。そんな時に行うバージョン管理関連の作業がコミットです。
コミットは保存価値のあるスナップショットを残す作業です。上の図を見れば、Gitのもとでクライアント側は実際に作業を行うワーキングディレクトリと、コミットによってスナップショットを残すローカルGitリポジトリ、そしてその中間段階のコミット対象を一時保存するステージングエリアが明確に分かれて管理されます。
コラボレーションのフレームワークについて話す前に、まず協力者の間でどのような場合にコミットをすべきかを明確に定義する必要があります。バージョン管理の基本単位がコミットだからです。実際にコラボレーションを行う際には、コミット以外にも様々な作業方法の基準について話し合っておくことが良いです。面倒な作業のように感じるかもしれませんが、一度基準を合わせておくことで不必要なコミュニケーションを大幅に減らすことができます。
では、個人的な意見としてコミットに関するいくつかのガイドを提案してみましょう。この内容を基に、自分のプロジェクトや状況に適した形でカスタマイズして適用すると良いでしょう。
コミットはできるだけ頻繁にするべきです
Gitの構造の下で、コミットはその状況でのソース全体のスナップショットを残す作業です。いつでもこの地点に戻って作業を再開することができるということです。では、コミットは頻繁にするべきでしょうか？それとも、時々するのが良いのでしょうか？少し曖昧な話ですが、それでも選ぶとしたら頻繁にするのが良いと言いたいです。実際、プロジェクトを進めていると様々な状況が生じます。今まで作業してきた内容の中でどの機能を削除すべきか、ある分岐で別の方向に進む際に追加した機能のいくつかを残したいといったことです。こういった様々な状況に対応するためには、頻繁なコミットが必要条件となるでしょう。もう少し具体的に言うと、2つの異なる機能であればそれぞれを分けてコミットするのが良いということです。
テストが終わった完全な状態のソースをコミットする
もう少し条件を具体化してみましょう。補完が必要な不完全な状態のソースをコミットしてしまったらどうなるでしょうか？後でその地点に戻った時に、不完全な状態を補完する作業を行った後に次の作業が進行可能になります。その補完作業は思ったより手間がかかる可能性があるため、できるだけ、というよりは常にテストが完了した完全な状態でコミットを行うべきです。もう少し厳密に言うと、コミットされるソースは本番サーバーに反映されても問題ない程度でなければならないということです。
コミットは機能動作や構造的変化の最小単位ごとに行うべきです
作業を進めているとリファクタリングが必要だと判断される場合があります。プロジェクトの初期には頻繁に発生する内容です。この場合、機能追加・修正作業と構造変更作業（リファクタリング）は必ず分けてコミットするのが良いです。これ以外にも、物理的な変化（ソースファイルを2つに分ける、内容を他のファイルに移すなどの作業）も別々にコミットすることをお勧めします。
コミットはビジネス的な機能単位で進行する
コミットされる単位はシステム的な区分（バックエンド、フロントエンド、データ）よりも、ユーザーの観点での機能単位で区分することをお勧めします。ビジネス的な機能動作のためのすべてのコードが一度にコミットされるのがより効率的であることは説明するまでもないでしょう。その機能を削除する際のことを考えてみると理解しやすいですが、その時にはその機能に関連するすべてのコードが消えなければなりませんよね？
実はこの他にも様々な考慮すべき状況があるでしょう。上で一般化して書いてみましたが、確かに実際の作業環境や作業者のスキルに応じてカスタマイズが必要になるかもしれません。開発スキルが非常に高い作業者であれば、頻繁なコミットはむしろ非効率を引き起こす可能性もあるでしょう。上記の内容を参考にして、作業状況や協力者の特性に適したあなた自身のコミットガイドラインを作ってみてください。それが効率的なコラボレーションフレームワークを構成する上で、最も先に行うべきタスクだからです。
