はじめに
こんにちは。risacanです。 
7月からIDCフロンティアUX開発部に配属になりRubyの勉強をしています。UX開発部に配属になるまでプログラミング経験は全くなく、MatzのこともGitのこともGithubのことも知りませんでした。
この記事では、そんな私がこの半年で出会ったダメダメコミットベスト3を発表したいと思います！ 
バージョン管理システムにおいて、コミットメッセージとコミット粒度が適切だと、ソフトウェアの調査がしやすい、コードビューしやすい、などのメリットがあります。しかしながら、世の中わかりやすいコミットばかりではありません。ダメダメコミットが溢れているのです！
この記事ではそんなわかりにくいコミット＝ダメダメコミットを紹介しながら、より良いコミットにする基本的なポイントをご紹介していきたいと思います。
よければお付き合いください。 
ダメダメコミット
第1位 コミットサブジェクトになんの情報もない
コミットサブジェクト（コミットメッセージの1行目）の情報が少なすぎる例です。
Githubのコミット一覧では、コミット日時とコミットサブジェクトが表示されます。たとえばバグ 
が発見され、発生原因のコードを調べようとしたとしましょう。上記の例では、3つのコミットサブジェクトがすべて「編集」で、どこをどのように編集したのかはわかりません。これでは、バグの発生原因となったコミットを探しだすのに膨大な労力と時間がかかるでしょう。バグフィックスが遅れてサービスにも影響がでてしまうかもしれません
ポイント
コミットサブジェクトを大切に！
コミットサブジェクトには、コミットの内容を簡潔に書きましょう 
2位 作業時間で区切ったコミット
コードを書いていて、時間的に区切りがついたところでコミットしてしまう例です。
コミットとは巻き戻せる単位です。休み時間がきたからといって、作業の途中で中途半端なままコミットしてしまうと後々大変です。コミットを巻き戻したとき、作業途中のファイルに戻ってしまう可能性があるからです。
ポイント
コミットは意味のある単位でわけよう！
作業時間ではなく、作業の内容でコミットを分けましょう
3位 インデント修正のコミットを分けない
（引用: https://github.com/idcf/idcf-dns-ruby/commit/fd573940ff58f342d14619519f901fcb5dcba266）
インデントの修正とソースコードの変更を一緒にコミットしてしまった例です。
インデントの修正が複数行にまたがって赤くハイライトされています。同じコミット内でUUIDの変更をしているのですが、他のハイライトに埋もれてしまい目立たなくなっています。これでは、コードレビューのときに気をつけて確認するべき重要な変更を見逃してしまう可能性があり、危険です。
ポイント
インデントの修正は1つのコミットにしよう！
プログラム的に意味のある変更とそうでない変更を区別し、それぞれの変更を確認しやすくしましょう
おわりに
いかがでしたでしょうか？「新入社員が半年で出会ったダメダメコミット」というタイトルでここまで書きましたが、実は上記の3点すべて私がやってしまったコミットです 
失敗は成功のもとということで、お許し下さい・・・ 