git commitメッセージに変更されたファイルを記載する必要がありますか？

50

git commitメッセージの最初の行では、変更が複数のファイルにまたがらない場合に変更されたファイルについて言及する習慣があります。たとえば：

Add [somefunc] to [somefile]

これは良いことですか、それとも不要ですか？

git

— マティー
ソース

84

バージョン管理ツールは、どのファイルが変更され、どのメソッドが追加されたかを確認できるほど強力です。これは、一般に、すでに存在するものを明らかに複製するログメッセージがログを汚染していることを意味します。

somefunc要件を満たすためのメソッドを追加しました。つまり：

機能を追加するには、
バグを削除するか
ソースコードをリファクタリングします。

つまり、ログメッセージでは、影響を受けた機能/バグやリファクタリングの目的を説明する必要があります。

— アルセニ・ムルゼンコ
ソース

5

理由についても説明する必要があります。他にどのようなオプションを検討しましたか、なぜこのオプションを選択したのですか？

— ジェイバズジ

2

コミットについては、コードをコメントするのと同じように、より高いレベルの観点から（つまり、情報が少なく、要約が多い）コメントします。個人的には、ファイル/モジュールレベル（git）に分解しますが、それはコミットが前払いで安く、本のように履歴を読むことができるからです。YMMV。

— エヴァンプライス

1

なんらかの理由で、同じバグに関係のない一連のファイルを一度にコミットする場合、夏前にファイル名とバグIDをリストすることを好みます。file.cppを知っている必要はありません：getMethod（）を追加しましたが、バグID＃10 file.cppがここにあります：彼らが複数のバグレポートにまたがる大量のファイルをコミットする場合、私は話をするでしょう、私はそれが本当に好きではないので。むしろ複数のコミットをしたいです。解決する問題ごとに1つ。

— ウィリアム

@William：また、1つのバグ修正に問題がある場合、最小限の手間で元に戻すことができます。1回のコミットで10個のバグ修正を組み合わせると、深刻な問題になる可能性があります。

— デビッド・ソーンリー

59

いいえ。コミットの内容を調べる方法はたくさんあります。コメントには、コミットの目的を説明する必要があります。

— ダン・レイ
ソース

30

TICKET / ISSUE NUMBERを追加することを忘れないでください。

チケット＃または問題＃を備えた機能または問題追跡システムがある場合は、必ずそのID＃をコミットに入れてください。それはあなたが取り組んでいた機能や問題についてもっと知りたい人に役立ちます。

私の最後のプロジェクトでは、コメントの最初の7桁がクリアクエスト（私たちの問題/機能追跡システム）からの有効な問題番号であることを確認するために開発されたマクロがありました。

— java_mouse
ソース

では、リファクタリングの変更をどのようにコミットしますか？

— ジュール

@Julesリファクタリングには、終了しないチケット＃があります

— -Caleth

@Julesの1つの方法論は、リファクタリングが「雑用」の種類の問題として追跡されるため、問題番号もあるということです。

— スコットマッキンタイア

@ScottMcIntyreこれは真実かもしれませんが、それが良い考えだとは思いません。リファクタリングは、日和見的に、またはリファクタリングされるコードに依存するコード開発プロセスの一部として、最適に実行されることがよくあります。Fowlerが言うように、「計画されたリファクタリングは[...]チームが他のワークフローを使用して十分なリファクタリングを行っていないことの兆候です。」または、より率直に言って、Ron Jeffries：リファクタリング-バックログにはありません！。

— ジュール

3

たとえば、複数のファイルへの変更を必要とする欠陥の修正をコミットするときに、そのようなことをします。これにより、変更セット内の個々のファイルを確認することなく、実際に変更された内容を簡単に伝えることができます。

単一ファイルの変更セットの場合、これは不要です。

最初の行は常に、障害やユーザーストーリーへのリンクなど、変更セットの高レベルの説明です。

— マイク・パートリッジ
ソース

3

コミットメッセージの説明に関連情報がある場合は、はい、それを含めます。情報の唯一のビットがファイル名自体である場合、いいえ。

たとえば、これは理にかなっています：「build_foo（）関数をfooutil.cからfoobase.cに移動しました。build_foo（）を使用したいほとんどのプログラムには既にfoobase.cが含まれているからです」

これは、「fooパラメーターを取得するためにfooutil.cのbuild_foo（）を更新しました。」

— アンディ・レスター
ソース

1

ここに別の視点を追加したいと思います。

私の答えは「はい」または「いいえ」です。しかし、通常は「はい」と答えます。

バージョン管理は、どのファイルが更新されているかを知るのに十分強力です。しかし、私たちがするとき

$ git log

コミットメッセージのみが表示されます。ほとんどの人がすること。

ログ自体を調べます。追加のコンテキストを追加します。例えば：

readme.md: Fix typo detected by language tool

よりも良い

Fix typo detected by language tool

ただし、変更によって複数のファイルが生成される場合は、少なくとも編集中のコンポーネントに言及してください。

API: Fix reset password not sent email to user

これを読むことで、修正されているエラーがAPIコンポーネントにあり、おそらくコードベースのAPIディレクトリにあることがわかります。

しかし、私たちはできる

$ git show COMMIT_ID --name-only

ただし、ファイルを取得するためだけのステップが追加されます。

— ヤナ・アグン・シスワント
ソース

0

これが単一のファイルのチェックインに役立つことがわかるのは、ファイル内の多くの場所で使用されている関数に変更を加えて、diffが乱雑になった場合だけです。それでも、最初に変更トラッカー＃と変更のプレーンテキストの説明を入れました。

— ダン・ニーリー
ソース

-1

ここでの本当の質問は、コミットの範囲がどのくらい制限されていると思いますか？関係のないさまざまな変更を1つのコミットで一緒にコミットするのを待つ場合、どのファイルがどのような目的で変更されたかを指定する必要があると感じるかもしれません。

ただし、単により狭いコミットをより頻繁に行った場合、単一のコミットでどのファイルが変更されたかを説明し、メッセージの目的を簡単に説明できます。

より多くのコミット、より頻繁に。これは、メッセージの冗長性を回避する方法です。

— ラッフィ
ソース

-2

すべきではない

興味のある人は誰でも歴史の変化を見ることができます

また、多くのファイルが自動生成される可能性があるため、大規模なシステムでは実行できません

— CodeART
ソース