ソース管理にコミットするときにコメントに何を入力すればよいですか？

私は孤独な開発者であり、ソース管理用のSVNサーバーを維持しています。これまでのところ、私は自分の変更をコミットする間、特定のことを行っていません。

私は以前のコミットを確認しているだけで、コメントを理解することができませんでした。

チェックインをコミットするときにコメントに何を入れますか？

これを読むことに興味があるかもしれません：https : //stackoverflow.com/questions/321720/best-practices-for-version-control-comments。

バグトラッカーを使用しておらず、そのためバグレポートのID /番号を含めることができない場合は、コメントで非常に説明的である必要があります。それ以外の場合、たとえば「Xに関する修正済みの問題」とだけ書いた場合、コミットの2週間後、何が問題だったかを思い出せません。その場合は、コミット前とコミット後のバージョンを比較して、バージョンを理解する必要があります。

アプリケーションを専門的に開発し始めたときは、バグトラッカーを使用していませんでした。コメントが非常に説明的である場合も（多すぎる場合も）、まったくコメントがない場合もあり、混乱していたことを覚えています。バグトラッカーIDを使用すると、コメントがより便利になり、さらにいくつかの単語を使用して、特定の変更を加えた理由を示すこともできます。また、たとえばEclipseなどのIDEには、コメント内（およびソースコード内）でバグトラッカーIDを検出するプラグインがあり、バグトラッカーのWebページへのクリック可能なリンクを提供できます。

以前のコミットのコメントで何を見つけると思いましたか？

その情報を次のコミットに入れてください。

場合によっては、チケットID、バグレポートまたは機能リクエストを表すチケットで十分な場合があります。

コミットコメントは、変更点を簡単に確認するためのものです。それらは参照用にあります。そのため、それらにどの程度の詳細を入力するかは、将来の時間を節約するために現在費やしたい努力に依存します。一般的に言えば、コミット時の少しの努力で、将来多くの時間を節約できる可能性があります。

たとえば、a <=をaに>、a ++をa --にループで変更するとしますが、説明的なコミットコメントは追加しませんでした。後で、反復の方向を逆にしたリビジョンを見つけるのは難しいでしょう。「何とかインデックストラバースの逆方向」とコメントした場合は、リビジョンログを検索することで、そのリビジョンを見つけるのがはるかに簡単になります。

これが、コミットメッセージに問題追跡情報を含めることが本当に良い考えである理由です。バグを修正したとします。その後、完全に修正されなかったため、後で問題が再開されます。元の修正のコミットコメントに課題追跡IDが記載されていれば、簡単に見つけることができ、後でその課題に関連するすべてのリビジョンを簡単に見つけることができます。

私はコミットしていることの簡潔な形を書く傾向があります。特定のタスクの場合は、メッセージにタスク番号を含めます。次のようなもの：

Changed foobar module to account for the new baz; created quux pages and data objects.

すべきでないことは、「おっと」や「追加されたコメント」（どちらも同僚によってコミットログに追加されたのを確認した）などのナンセンスなものを書くことです。単一のファイルがチェックインされ、コミットメッセージ "Comment"（正確な引用）が表示されました。何が追加されましたか？以下の影響があるもの：

if (z == true) { 
    x = y; // x is being overridden here... <--- added in commit
}

そして、いいえ、コミットの数によって測定されるわけではありません。

これはすべて、プロジェクトの管理方法に帰着すると思います。私にとって、リリースビルドにプッシュしたい機能が終了するたびにコミットする傾向があります。私の場合、すべての機能がコミットされるため、コメントとして機能のストーリーと問題番号を使用します。バグを修正する場合も同様です。私はスパイクから始め、ストーリーを導き出し、そのストーリーを使用して必要な変更を説明し、もう一度コメントにストーリーを含めてソース管理に取り組みます。

発行ID。

ほとんどの課題追跡には、コミットメッセージから課題IDを解析し、課題のあるコミットをグループ化できる形式があります。

Issue Trackerを使用しない場合は、使用する必要があります。あなたが単独の開発者であるかどうかは関係ありません。別の回答で詳しく説明しました。

課題追跡を使用します。あなたが孤独なオオカミであるかどうかは関係ありません。機能であろうとバグであろうと、プロジェクトで行うすべてのことを追跡してください。機能/コンポーネントリストを作成します。本当に重要なコンポーネントをバージョン1.0としてマークし、それ以外はすべてバージョン2.0としてマークします。そして、2.0とマークされているものをすべて削除します。

OK、質問はより長い回答のmod通知を受け取ったので、拡張する必要があると感じています：

はい、問題IDをコミットコメントに入れるだけです。ソロプロジェクトの場合、チームプロジェクトの場合はまったく別の話です。私は問題IDだけを置くことを主張しているわけではありません。そこにはさらに何かがあるはずですが、

1. ソロプロジェクトでは、何も文書化しないことは非常に魅力的です。
2. 課題IDを入力すると、デフォルトで課題トラッカーの設定プロセスが完了したことになります。
3. それで十分です。

ソロを開発する際に課題追跡を効果的に使用することは、コメントをコミットするよりもはるかに大きな成果です。コメントに何か役立つものを追加する動機があればいいのですが、そうではありません。

私は通常、チェックインの目的を一番上に置きます。これは、機能リクエストの名前、チケット番号などです。

次に、影響を受けるファイルのリストと、各ファイルで必要な特定の変更を追跡します。これは、プロジェクト/フォルダーではなく、ファイルの変更履歴を見ているときに特に役立ちます。

何かのようなもの

Ticket 101 fix web service exception when uploading widget

Bug was caused by users uploading incomplete widgets (widgets without wonkers)

webservice.cs:  
  improved post validation for incomplete widgets
  added default exception handler to ProcessWidget
widget.cs:  handled the SqlException when inserting widgets without wonkers

一般的に、あなたがそのコミットで取り組んだことは良いスタートです:)

（好奇心から...意味が分からなかったら何を書いてたの？）

コードに加えた変更、およびバグ修正、新機能、機能の中断、ライブラリの変更などに限らず、関連性のある可能性のあるもの。もちろん、コードは少しずつコミットされるため、上記のすべてはありません。たとえば、バグを修正する場合、複数の変更を加える可能性があります。これは、バグを修正するための複数のコミットになりますが、特定のバグを修正するために行った変更は何ですか。

コミットログの最も重要な情報は、「何を」ではなく「なぜ」です。

変更の短い要約が役立つ場合がありますが、通常、その情報はdiff自体から取得できます。それが欠けていてもそれは大きな問題ではありません。

コミットログを振り返ると、なぜその変更が行われたのかを知りたいでしょう。バグIDは、その質問に答えるのに非常に役立ちます。時には、より多くの説明が必要です。たとえば、不正な入力の問題を修正する場合は、どの入力が問題の原因であるかを説明し、それが自明でない場合は、どのように発生するかも説明します。

私たちはプロジェクトでassemblaを使用しています。実行する必要があるすべての機能/バグを使用してカードウォールを構築し、コミットするときにこのチケットを参照するだけです

例えば：

see #243
 - Grid listed all users with an income more then 1000$ but not the ones that have
   exactly 1000. Added a >= in the file xy.cs on the line xyz

このようにして、変更をすばやく特定し、いくつかの間違いを簡単に見つけることができます