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

Question

ログみると真っ白で、なんで変更したのか、さっぱりわかりません????

どうしたらいいですかねー。

Answer 1

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

Comments

[matobaa]

勇気をもらえました。ありがとうございます。

- ポリシーを明文化し
- テンプレートを作り
- トレーサビリティを確保し
- フックスクリプトで型にはめる
ですね。やってみます！

よく引き合いに出される、山本五十六の言葉を思い出しました。
やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。
話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。
やっている、姿を感謝で見守って、信頼せねば、人は実らず。

Answer 2

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

Comments

[matobaa]

やー、コミットログの価値を理解してもらいたいんだ

[sho_cs]

強制でも書き始めれば慣れてきたり、価値を理解するきっかけになると思います。

[退会済みユーザー]

コミットログって管理者、チームリーダーにとっては大変大きなメリットです。ただチームメンバーにとってコミットログが書かれていることってメリットを感じにくいんですよね。実際コミットログがなくても困らないんです。「価値を理解」は難しいんじゃないですかね…

[sho_cs]

過去の改修内容をコミットログを手がかりに探すことがたまにありますがコメント書いてなくて後悔する事ありますし、コメント書いていてよかったと感じること有りますよ。
直近のものだと確かにメンバはメリット感じにくいかもしれませんね。

[退会済みユーザー]

メリットがないというのはありません。書かない人にとってはやはりメリットを感じていないからということです。書くことを当たり前の習慣にするには、強制するのが一番簡単な方法だと思ってます。

メンバーにとって、良かったと思うのはコミットログよりソース中のコメントの方が役に立つし、特定のコミットでどのファイルが編集されたかより、特定のファイルがどのコミットで編集され、誰が編集したかは使う場面がありますが、svn log で特定ファイルの編集履歴が追跡できてしまいますよね。「コミットメッセージを手掛かりにする」という場面があまりないんですよね。特に「やらされている意識」でやっているメンバーにとっては…

「仕事なんだからやれよ。」って話なんですけどね。

メッセージをだらだら書かせるより、Redmine のチケット番号の入力だけを強制する方が運用は楽だと思ってます。ex) refs #1234

Answer 3

emoji prefixを使ってコミットログを可愛くしましょう。可愛さが命です。

Comments

[harashow1701]

可愛さは悪ですか。

[harashow1701]

お、マイナス評価３くらい最初ついたのに持ち直したw

Answer 4

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

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

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

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

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

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

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

Answer 5

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

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

Answer 6

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

Comments

[matobaa]

もしや同じプロジェクトに居るのではないかと思うくらい、見透かされた気になりました。刺さりました。こういう指摘は大変ありがたいです。痛かったです。反省します。

Answer 7

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

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

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

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

Comments

[matobaa]

うーん。やはりコメントを書かないというのはいかがなものかと思います。
ソースを修正するのには理由があるはずなので、「XXXに関する作業」というポインタを入れてもらいたいです。別のチームでは、 refs #NNNN WIP と書いてます。

[buibui80]

経験則になりますが、
成果単位でなく作業バックアップのコミットを許容する運用の場合、
似たようなコメントが連続することがあり成果コミットを見つける事が面倒な事がありました。
コメントの書式ルールを決めて作業と成果を区別できるようにする事も検討しましたが、
「XXXに関する作業」の「関する作業」についてコメントだけでは表現できないことやそのフォローも不足するので、
成果以外のコミットに関しては業務日誌（Redmine）で管理するようになりました。

[matobaa]

ソースのannotateとかblameとかから変更理由をたどりたいので、やはり refs #NNNN は書いてほしいです。gitだったらあとからコミットをまとめられるので、バックアップ目的などの一時的なコミットにメッセージを書かないのもアリだと思います。

[buibui80]

コミットコメントの種類を設計項目から一覧化して、
その１項目をコピペしてもらったら担当者はコメントを考える労力なく記入してくれるのではないでしょうか？
または設計書の項目番号など。

設計書に無い単語を用いられると後々確認にも時間がかかりますし、
作業内容を誇張や過少、詐称や勘違いで書き込む余地を残さないことも大事だと思います。

Answer 8

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

Answer 9

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

Comments

[matobaa]

ベストプラクティスを模索中です。
http://rochefort.hatenablog.com/entry/2015/09/05/090000 の
http://chris.beams.io/posts/git-commit/ とかとか。

Answer 10

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

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

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

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

Answer 11

普通に

---

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

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

---

多分前回の変更から”ここ”と”ここ”を変更した。

履歴のコメントを見てもわからないので悪しからず。。。

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

Comments

[matobaa]

チームリーダーにお願いするのがいいのかなあ……書かない筆頭なんですけど

[JunTomizawa]

「書かない筆頭」と諦めたらそこで終わりです。
正しいことを正しいと言えないことがあるのであればそこは変えなければいけません。

本当にそれが正しいのであればどんな立場の人間にも言うべきです。
たとえそれが自分の会社の社長であったとしても。

間違ったことを続けるのが社の長なのであればそれに付き合って社が潰れるのを待つ必要はありません。
あくまで自分が考えた結果の人生ですから、悔いのないようにしなければ。

チームリーダーがコメントを書かないのであれば、その上（バージョン管理を導入した本人）へ訴えてはいかがですか？

[matobaa]

「バージョン管理を導入した本人」がすなわち私なので、悩んでいます。

仰るとおり、安西先生がいうところの
最後まで…希望をすてちゃいかん。
あきらめたらそこで、試合終了だよ。
ということですね。
しゃーない、やるかあー

背中を押していただき、ありがとうございます。

[iwamoto_takaaki]

変更点そのものは、バージョン管理が教えてくれるので、なんて書いたらいいのかわからないんだとおもいます。

なので、”書いて下さい”ではなく、”この変更は何の変更なのですか”と聴いた上で”この場合はXXXというコミットログを書いてくれると変更内容がすぐに分かります。”と一家ずつ説明して回るのが良いと思います。

[JunTomizawa]

わからなくても白紙はね・・・
わからないなりに頑張って書いてみるとかが無い時点で論点が違うと思います。

変更点を確認すらしているのかわからないですが、コメントを書かない人が変更点を確認してコミットしているのですかね？

[iwamoto_takaaki]

わからないなりに頑張るのは、書くことで確実にメリットがあることを信じている場合だと思います。バージョン管理に馴染みがなく、コミットログから変更点を探したことがないのなら、メリットを信じられないと思います。（ホントは”んなもん、ちっと考えりゃあ、わかる！”という意見にも同意したい。）

逆に、何を書いたらよいかわからない状態で無理に書かせると”変更点をコミット”とか”[filename]を変更”とか”バグを修正”とか書くことになります。これでは、書くだけ無駄かなと・・・

[JunTomizawa]

いえ、わからなくても書いた内容が間違っているのならばそこを指摘し発展していけると思います。

メリットについてはぶっちゃけ話した上での導入じゃないんですかね？
そうでないなら
”なんとなくバージョン管理システム導入したので使ってねー(*´ω｀*)”
って言ってもちゃんと使ってはくれないですよね、その場合はもう一度導入の説明からやり直しですかね。

[iwamoto_takaaki]

書いてるなら指摘出来るという意見、とてもわかるんですが、ホントに”変更点をコミット”とか書く人だと暖簾に腕押しというか・・・愚痴ですね、すみません。

どのような方法にせよ根付かせるには、地道に話を重ねるしかないってことですよね。

[matobaa]

もう一度導入の説明からやり直します。がんばります。

Answer 12

書く習慣を付ける様に提案したほうがいいと思います。

Answer 13

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

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

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

Comments

[matobaa]

「とりあえずコミットメッセージこんなふうに書いてね」というメールを送ったら、仲間が増えました!

いまは歯抜けながら、変更理由を書き始めてくれています。近いうちに、変更箇所から変更理由を特定する (その過程の中でコミットメッセージを使う) というデモをしたいと思ってます。

Answer 14

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

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

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

Comments

[matobaa]

いいですね。ちょっと書かないと制約が不便。
「もしある人物が問題に関係があって、しかもその問題を抱えていないなら、何かをやってそれをその人物の問題にしてしまおう」ってやつですね。やろうやろう

Answer 15

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