コミットログを書く文化がないチーム

「文化」って、根付かせるには時間が掛かるものだから、まず第一に「諦めない」こと。
価値や必要性を理解してもらうのも重要だけど、習慣化させるための最初のステップは、何をどのように書くかべきかという「ポリシー」を明文化すること。
ポリシーが決まったら、解りやすいテンプレートを作成すること。
何らかの方法で課題管理（バクトラッキング、変更管理など）を実施しているはずなので、その「管理番号」の記入方法（フォーマット）を明確に決めることは特に重要。
その上で、フックスクリプト等を利用して、所定フォーマットのコメント記入がなければコミットできないようにすれば、いずれ定着するはずだと思います。
それから、コミットの『種類』を意識させることも重要だと思います。
たとえば、バグフィックスなのか機能追加なのか、それともリファクタリングなのか、あるいは作業の完了なのか、それとも途中経過（特定の工程が完了）なのか、などなど。

サーバーの設定でコミトログの記述を強制することができます。
Subversion pre-commitを用いたhookでコミット時メッセージを必須＋日本語でのエラー表示を行うの巻

- 目の前の現実を変えるために必要な「７つの知性 http://globis.tv/movie/?e=1714

目の前の現実を変えるための「戦略」は、まずは自分がコミットログを書くことかもしれません。

文化がないのであれば、まずかんたんなところからはじめて、
しだいに発展させていく（イテレータを回す的な）のが良いと思います。

たとえばコミット種別の例として、「バグ修正、致命的なバグ修正、新規機能追加、機能修正（非バグ）、仕様変更、リファクタリング、コメントアウトなどの無効化、削除、バージョンアップ、変更取り消し」などがあります。（これをこのまま採用しろ、というわけではなく、あくまでイメージするための例です）

最初はこういうのをコピペするだけでもいいと思います。

いや導入側としては、「もっと高度に使ってほしいんだけど……」という感じでしょう。文章のテンプレートやフォーマットとか、（日本の場合は少ないがOSSの場合）英語で書くとか、フックスクリプトでチケットナンバーのような数字を自動的に入れるとか、流儀や作法はいくらでもあります。

でも受け入れ側は、「やらされている」と感じがちです。今の仕事にさらに積むから、あれもこれも要求されると感じて、人間の心理としてうんざりするのです。

たいてい導入側はよそのビルを見て「うちもこうしよう！」と思うわけですが、
いきなり更地にビルを建てようとするより、小屋を建てるほうがかんたんです。

そこで、「抵抗できないほどかんたんなことを、すぐにやり始める」のが良いと思います。

普通に

---

コメント分かりづらいです、書いて下さい。

---

っと直接言っていいと思います。
それが言いづらいのであれば、コメントに

---

多分前回の変更から”ここ”と”ここ”を変更した。
履歴のコメントを見てもわからないので悪しからず。。。

---

とでも書いておいてはいかがですか？

ないよりはあった方が良いのはわかっている。
だけど面倒だと思う人がいるかもしれない。
という事ですかね。

まずひとつは。
こういうのは個々でばらばらに始めるものでもないので、（その後どうなるかは別として）まずは全員で「やりましょう」という意思統一することですよね。それには、しっかり目的を伝えて、提案することから始まると思います。
まずは全員がいる場で議題として提示することじゃないですかね。
（チームで決めたことを破る奴は、ただそいつが悪いだけですから）

思うに、
バージョン管理の導入をしたということなので、他にもバージョン管理のルール的なものは、ある程度あるはずですよね。例えば、「こういう命名規則のブランチ名にしましょう」とか「こういうflowで運用します」とか「リリース後はタグを打ちましょう」とか。
そういうルールの中に、コミットログは何の目的で何を修正したのか完結に書きましょう的なルールが加わるだけじゃないかなと思います。

私が思うところのコミットログは、
私個人の作業としては不要ですが、チームというのはメンバーが変わりますし、過去の経緯を完全に覚えている人なんてごく稀ですし、自分のために書くのではなくて、その時のチームメンバーが誰であれ過去の修正経緯が分かるという点で必要かなと考えます。
逆に言えば、他の方がおっしゃってるように、タスク管理のツールと照合できたり、リリースノートが全て残っているとか、他で管理が出来るならそういう手段もあるのかなと。

チャンスです！
ルールを整備して、一貫性があって、役に立つコミットログを目指しましょう。

commitログに限らず基本的にコメントってのは大事ですよね....
ソースコードを記述する際にも変数名などがわかりづらくなってしまう場合などにもコメントはできるだけ残すようにしていますが...

最初はコメントを書く習慣がありませんでした。
理由は作業の合間のバックアップとして都度コミットしていたからです。
なので関数を書きかけの状態でも構わずコミットしていました。

今はコメントの有無で状態を判断しています。
コメントのないコミットは作業バックアップとして扱い、
コメントのあるコミットは機能追加や修正などの成果を示すものとして扱っています。

管理側からすればコメントは入れて欲しいのですが、
開発側からすればコメントが書ける状態でないけどバックアップとしてのコミットが必要なこともあるので、
どういう状況でコメントが必要かルール決めしておけば良いと思います。

うちでは進捗とリスケの参考にするため都度バックアップ的なコミットは推奨しています。
特定の人物の進捗が遅れているけど日別のコミットを見てみると
バグにより巻き戻し作業が発生していたということも確認できて評価材料にもできますし。

(質問の意図を誤読した回答だったため、自主的に消去)

私はいつも一人でやってしまうので、書かない人です。しかし、皆さんがおっしゃっているように過去の変更点を覚えているわけでもないので修正する場合は思い出すのに苦労します。(時には思い出さずに問題解決のサブルチーンを付け加えてしまいます。実に美しくないプログラムになりますが)
書こうとするのですが、意外とどう書けばよいかわからず、細かく書くとプログラムより長い文章になり、プログラムが読みにくくなるのでやはり書かなくなります。
私は独学でやってきたせいか、書きたくても書けないという悩みを持つ人間となってしまいました。。

JIRAとStashを連携していて、Gitでコミットしてもマスターブランチには承認者がStashで承認しないとマージされないみたいな仕組みがあれば、コミットメッセージを書かないといけない状況になると思うんですがどうなんでしょうね？

前にいたチームでgitのコミットメッセージは必ず英語で書かないといけない。それがGitHubのルールだっ！といって、別に社内のGitのリポジトリなのにGitHubのルールを推し進めようとしていた人がいました。
日本人しかいないチームで「modified the ～」だけ書かれていてもわかんないですよね。
何のために書くのか、伝わらないのは伝える側のほうが悪いと思っています。

まずは緩いなりにちょっと書かないと制約が不便なくらいの縛りで進めてみてはと思います。

# ２か月ほど経ちましたが、いかがな状況でしょう...

すでに多くの方からコメントいただいているとおりですが、
書かない人は、なぜ、何のために必要なのかが理解できていないのですよね。
あまり良くないかも知れませんが、一度痛い目に遭わないと・・・
例えばコメントがないためにコードを頭っから読み解きなおすとか、
メンテナンスに想定以上の工数がかかって大赤字プロジェクトにしてしまったりとか...
果ては現場で徹夜とか...ね。
でも、そんなネガティブな対処を推奨するわけにはいかないかと思いますので、
とりあえずはここの回答の中からピックアップするなりして、こういうことが
あるので必要なことなんですといったようなアプローチで、地道な布教活動を
諦めずにしつこく行うことでしょうか。
確かに強制的に書かせるのもアリですが、なぜ、何のためにがわかってないと、
テキトーなコメントを書いてしまい、余計わからなくなることもままあります。
それに、内容とコメントが違う...なんてこともあるので、やはり理解した上で残すような
文化を作っていくしかないかと。
また、いくつかコメントのテンプレートを用意しておくというのも良いと思います。
(なんだかなぁと思いますが、極力手間を省いてあげる...)

私も過去似たような経験がありますので大変だということはわかります。
諦めずに継続を!