Gitのブランチをどのタイミングで切って、マージしていくかなども非常に大切ですが、ブランチやマージをするよりも頻繁におこなうコミットについて、あらためて基本に立ち返ってみましょう。
一つ一つのコミットを綺麗に積み重ねていくことは、ブランチを切るタイミングやマージ、歴史の改編などを容易にすることができます。コミットが綺麗に積み重ねられていないとマージや歴史改変で苦労するでしょう。
Gitのベストプラクティス（原文）に乗っかるためにもgit commitする前に以下のようなことをチェックしましょう。
Gitの操作に慣れている人はPushやMergeをする前に今回紹介するようなことを元にしてコミットの歴史を綺麗に整えましょう。
1コミットに1つの対応
1コミットにはあれこれ詰め込めすぎるべきではありません。例えば以下のような2つのことがあったとします。
- Aの機能を追加
- Bの機能のバグを修正
2つの対応を1コミットにしてしまうと、片方の機能に関する歴史改変をするときに不具合があります。それぞれ、1コミットずつにわけで、2コミットするべきです。
不要な空白やタブをコミットしない
不要な空白やタブ改行をコミットに含めるべきでありません。特に行末に入れてしまうのに注意してください。
git diff --check
などで、コミット前にチェックしてからコミットしましょう。
タブとかスペースとかインデントの話は下記が参考になります。
不要なファイルをコミットしない
不要なファイルはコミットに含めてはいけません。~（チルダ）や#（シャープ）の付いたバックアップファイルなどを不用意にコミットに含めないように.gitignoreで管理対象からはずすように設定しましょう。
コードで自動生成されるデータやファイル、必要でないログも同様に含めるべきではありません。
コメントアウトしたコードをコミットしない
なんとなく不安だからという理由で、コメントアウトしたコードをそのままコミットすべきでありません。その不安を解消するためにバージョン管理を実施しているのですから。
コメントアウトされたままのコードは、他の人が見て不安を覚えるコードです。何かあるのではないだろうか？と、誰もが触りにくくなります。そして、コードは腐っていきます。そして「怪しいなぁ」という異臭を放っていくようになるのです。
典型的な悪い例について、下記のサイトが参考になります。最終的にコードよりもコメントの方が難解になっています。
テストコードを含めてください
バグ修正はもちろん、機能の追加についても、テストコードを“必ず”含めてください。
テストが正常に通過したものにしてください
付属のテストスイートがすべて正常にパスすること。新たに作成したテストがパスすることを確認したコードを最終的に含めてください。
テストがないのはレガシーコード
せめて、これから追加していく機能にはテストコードを。テストできるところからテストコードを。
「やりにくい」「めんどくさい」なんて言葉だけでは何も変わりません。
1行、1件のテストコードの積み重ねが現状を変化させてい唯一の方法です。
コミットメッセージの1行目は”短い説明”
英数字で50文字以内にすることを推奨します。短すぎてもわかりにくくなるのでいけません。
内容・理由・意味などを知らない相手によくわかるように述べること。
— せつめい【説明】 角川必携 国語辞典
50文字以内の“説明”にしてください。オレオレ語で書かれた自分しかわからないメモにしないでください。
コミットメッセージのスタイル
日本語よりも英語を利用して、行頭に動詞（現在形のみにする）を置くことを推奨します。ある程度、統一されたスタイルは容易にコミットログを理解するための助けとなります。
日本語でコミットメッセージを書くと
- 決済に不具合があるバグを修正しました
- メンテナンスモードを追加しました
日本語の場合、動詞を後ろに持ってこないと違和感ある文章になり、最後まで読まないと文章が理解できません。
英語でコミットメッセージを書くと
- Fix a bug in settlement
- Add maintenance mode
英語の場合、行頭を見るだけで、自分が探しているログ（修正？追加？）かどうかある程度は判断できます。中学英語で理解できて、書けるぐらいの明確で簡素な文章が書く方も読む方も負荷が少なく、良いコミットメッセージとなるでしょう。
下記の記事はコミットメッセージの書き方がとても参考になる記事です。
コミットメッセージのボディは有意義な内容にする
コミットメッセージは1行目に概要となる簡易なメッセージを書き、2行目は空白にして、3行目からさらに詳しいコミットメッセージを書いてください。
この詳しく書く内容は有意義な内容になるように記述してください。
- 今回の変更が解決する問題
- 問題を解決した方法について
- 代替え方法を検討した内容について
何もかも忘れた、未来のあなたに向けて、書く気持ちで書いてみましょう。
他人が理解できるメッセージ
あなた以外のプログラマが、あなたが不在の時に理解できるコミットメッセージかを再度確認してください。例えば、あなたのチームの新人が理解できるかどうか考えてみましょう。
さぁgit commitしよう！
コミットメッセージを綺麗に構築して、コミットしていくことは、柔軟な歴史改編をおこなっていくための土台を作っていくことになります。
そもそも歴史を圧縮したり整理したりする基本は学んでおきましょう！そうすれば、ローカルリポジトリには気軽にコミットして、pushやmergeの前に今回確認したことを意識して、git rebaseなどで過去のコミットを綺麗に書き直すということもできるようになります。こういった使い方が分散バージョン管理のメリットを享受できている良い例になります。
Gitの操作や知識などを十分に身につけている方は、PushやMergeをする前の最終的なコミットログの内容をどういう風にすべきか？という風に読み替えて頂ければと思います。pushやmergeやpatchを送る前にチェックしてみてください。
GitとGitHubの様々な現場での豊富な活用事例はこちらが参考になります。
Gitのベストプラクティスを補助するツールであるgit-flowをワークショップ形式で学べる記事は下記が参考になります。
コミットメッセージの書き方を始めとしてGitとGitHubを使った開発ワークフロー全体を包括的に解説している書籍は下記になります。
