質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.51%
Git

Gitはオープンソースの分散バージョン管理システム(DVCS)です。

Mercurial

Mercurialとはオープンソースの分散型バージョン管理システムです

Subversion

Subversionは、使い方はCVSによく似た、CVS(Concurrent Versions System)を改良したバージョン管理ツールです。

Q&A

15回答

14856閲覧

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

matobaa

総合スコア2493

Git

Gitはオープンソースの分散バージョン管理システム(DVCS)です。

Mercurial

Mercurialとはオープンソースの分散型バージョン管理システムです

Subversion

Subversionは、使い方はCVSによく似た、CVS(Concurrent Versions System)を改良したバージョン管理ツールです。

1グッド

18クリップ

投稿2015/07/09 15:20

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

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

mondaminZ👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答15

0

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

投稿2015/07/09 22:14

pi-chan

総合スコア5936

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

matobaa

2015/07/09 22:46

勇気をもらえました。ありがとうございます。 - ポリシーを明文化し - テンプレートを作り - トレーサビリティを確保し - フックスクリプトで型にはめる ですね。やってみます! よく引き合いに出される、山本五十六の言葉を思い出しました。 やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。 話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。 やっている、姿を感謝で見守って、信頼せねば、人は実らず。
guest

0

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

投稿2015/07/09 15:38

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

matobaa

2015/07/09 15:54

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

2015/07/09 16:33

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

退会済みユーザー

2015/07/10 06:11

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

2015/07/10 06:21

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

退会済みユーザー

2015/07/10 07:39 編集

メリットがないというのはありません。書かない人にとってはやはりメリットを感じていないからということです。書くことを当たり前の習慣にするには、強制するのが一番簡単な方法だと思ってます。 メンバーにとって、良かったと思うのはコミットログよりソース中のコメントの方が役に立つし、特定のコミットでどのファイルが編集されたかより、特定のファイルがどのコミットで編集され、誰が編集したかは使う場面がありますが、svn log で特定ファイルの編集履歴が追跡できてしまいますよね。「コミットメッセージを手掛かりにする」という場面があまりないんですよね。特に「やらされている意識」でやっているメンバーにとっては… 「仕事なんだからやれよ。」って話なんですけどね。 メッセージをだらだら書かせるより、Redmine のチケット番号の入力だけを強制する方が運用は楽だと思ってます。ex) refs #1234
guest

0

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

投稿2016/07/05 09:50

harashow1701

総合スコア854

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

harashow1701

2016/07/13 08:37

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

0

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

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

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

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

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

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

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

投稿2015/07/17 11:47

LLman

総合スコア5592

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

投稿2015/07/11 17:01

katoy

総合スコア22322

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

投稿2015/07/09 23:48

編集2015/07/12 21:02
jun68ykt

総合スコア9058

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

matobaa

2015/08/31 02:15

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

0

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

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

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

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

投稿2015/09/07 15:47

buibui80

総合スコア1033

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

matobaa

2015/09/08 09:29

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

2015/09/08 10:30

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

2015/09/08 11:52

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

2015/09/08 14:44

コミットコメントの種類を設計項目から一覧化して、 その1項目をコピペしてもらったら担当者はコメントを考える労力なく記入してくれるのではないでしょうか? または設計書の項目番号など。 設計書に無い単語を用いられると後々確認にも時間がかかりますし、 作業内容を誇張や過少、詐称や勘違いで書き込む余地を残さないことも大事だと思います。
guest

0

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

投稿2015/09/05 19:24

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

投稿2015/07/14 12:54

tohshima

総合スコア374

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

0

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

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

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

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

投稿2015/07/14 04:53

supikid

総合スコア139

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

普通に


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

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


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

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

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

投稿2015/07/09 15:27

JunTomizawa

総合スコア248

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

matobaa

2015/07/09 15:55

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

2015/07/09 16:36

「書かない筆頭」と諦めたらそこで終わりです。 正しいことを正しいと言えないことがあるのであればそこは変えなければいけません。 本当にそれが正しいのであればどんな立場の人間にも言うべきです。 たとえそれが自分の会社の社長であったとしても。 間違ったことを続けるのが社の長なのであればそれに付き合って社が潰れるのを待つ必要はありません。 あくまで自分が考えた結果の人生ですから、悔いのないようにしなければ。 チームリーダーがコメントを書かないのであれば、その上(バージョン管理を導入した本人)へ訴えてはいかがですか?
matobaa

2015/07/09 22:57

「バージョン管理を導入した本人」がすなわち私なので、悩んでいます。 仰るとおり、安西先生がいうところの 最後まで…希望をすてちゃいかん。 あきらめたらそこで、試合終了だよ。 ということですね。 しゃーない、やるかあー 背中を押していただき、ありがとうございます。
iwamoto_takaaki

2015/07/11 16:01

変更点そのものは、バージョン管理が教えてくれるので、なんて書いたらいいのかわからないんだとおもいます。 なので、”書いて下さい”ではなく、”この変更は何の変更なのですか”と聴いた上で”この場合はXXXというコミットログを書いてくれると変更内容がすぐに分かります。”と一家ずつ説明して回るのが良いと思います。
JunTomizawa

2015/07/11 16:36

わからなくても白紙はね・・・ わからないなりに頑張って書いてみるとかが無い時点で論点が違うと思います。 変更点を確認すらしているのかわからないですが、コメントを書かない人が変更点を確認してコミットしているのですかね?
iwamoto_takaaki

2015/07/12 04:43

わからないなりに頑張るのは、書くことで確実にメリットがあることを信じている場合だと思います。バージョン管理に馴染みがなく、コミットログから変更点を探したことがないのなら、メリットを信じられないと思います。(ホントは”んなもん、ちっと考えりゃあ、わかる!”という意見にも同意したい。) 逆に、何を書いたらよいかわからない状態で無理に書かせると”変更点をコミット”とか”[filename]を変更”とか”バグを修正”とか書くことになります。これでは、書くだけ無駄かなと・・・
JunTomizawa

2015/07/12 10:11

いえ、わからなくても書いた内容が間違っているのならばそこを指摘し発展していけると思います。 メリットについてはぶっちゃけ話した上での導入じゃないんですかね? そうでないなら ”なんとなくバージョン管理システム導入したので使ってねー(*´ω`*)” って言ってもちゃんと使ってはくれないですよね、その場合はもう一度導入の説明からやり直しですかね。
iwamoto_takaaki

2015/07/12 16:12

書いてるなら指摘出来るという意見、とてもわかるんですが、ホントに”変更点をコミット”とか書く人だと暖簾に腕押しというか・・・愚痴ですね、すみません。 どのような方法にせよ根付かせるには、地道に話を重ねるしかないってことですよね。
matobaa

2015/08/31 02:17

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

0

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

投稿2016/07/08 04:40

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

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

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

投稿2015/09/15 02:44

schi_heil

総合スコア78

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

matobaa

2015/09/15 08:19

「とりあえずコミットメッセージこんなふうに書いてね」というメールを送ったら、仲間が増えました! いまは歯抜けながら、変更理由を書き始めてくれています。近いうちに、変更箇所から変更理由を特定する (その過程の中でコミットメッセージを使う) というデモをしたいと思ってます。
guest

0

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

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

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

投稿2015/09/10 03:58

tiki0108

総合スコア13

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

matobaa

2015/09/10 04:04

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

0

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

投稿2015/07/16 06:36

YosiyukiUsijima

総合スコア42

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.51%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問