コミットメッセージは現在時制または過去時制で書かれるべきですか？[閉まっている]

それで、あなたがより直感的に優れていると思うのはどれですか？

Fixed the XXX bug in YYY
Fix the XXX bug in YYY
Fixes the XXX bug in YYY
Fixing the XXX bug in YYY

根拠を提供してください。一般的な観点から質問していることに注意してください。つまり、これを好みのsvn / cvsツールやプログラミング言語に関連付けようとするのではなく、あらゆるツールやプログラミング言語に適用すべき/適用できるものと考えてください。

これらのメッセージは、他の開発者に表示されると思います。彼らはまだ変更を適用していません、そして「この変更セット/パッチを適用するとどうなりますか？」という暗黙の質問があります。「YYYのXXXバグを修正」します！

コマンドとしてそれらを書く他の動詞の場合は、より自然に見え、特定の目標を前もって持っている場合にうまく機能します。作業が完了する前に、前もってテストとともにコミットの要約を文字通り書くことができます。

私はそれに大きな重点を置いていませんが、私にとってこれは一貫性を維持しながら抵抗が最も少ない道です。

私は個人的に過去形（「修正済み」）で進みます。コミットするまでにバグが修正されている（またはコミットしない）ためです。

現在の時制でコミットメッセージを表示することを好みます。このようにして、メッセージはdiffが何をするかを説明します（そのdiffをプルするか、そのコミット全体を別のブランチにプルするためです）。したがって、コミットメッセージはそれが「行った」ことを説明しません...コミット自体が「行った」ことを説明します。だから現在時制である必要があります。

差分を単独で見て、それを適用するかどうかを決定しようとしていると想像してください。タイトルが過去形であるのは意味がありません。

IMHOコンテキストを考慮する必要なく説明的なものにしたい場合、「修正済み」が間違いなく唯一の正しいバリアントです。

直感について-私がいくつかの変更ログを見ると、単語が使用されているコンテキストを知っているのでバグが修正されたことを意味することは間違いなく理解できますが、単語がこの自己で書かれていると、私の脳ははるかに迅速にそれをキャッチします-方法を指定します。

「修正」は、パッチが何をするか（目的）を説明するだけでなく、バ​​グステータスとしても解釈され、作業中でまだ解決されていないことを意味するため、最悪の選択である。

Fix the XXX bug in YYY
Teach the XXX to be more ZZZ
Correct typos in javadoc

一般に：{命令動詞} {影響を受けるオブジェクト} {オプションの修飾子}

命令セットは、パッチセットを検討しているときにすべてのユースケースに適合します。

• ここで何をしますか？
• このパッチセットは何をしますか？
• なぜこのパッチセットが作成されたのですか？（xxxバグを修正する...）
• yyyのxxxバグを修正する必要があります。これをすでに実行している別のブランチでコミットはありますか？

あなたの選択に関係なく、私は一貫性が読みやすさを非常に助けます。1つを選んで、それに固執してください。

現在のコミットについて現在形で書くことは良い考えだと思います。過去形で以前のコミットを参照すると、より明確になるからです。

それは本当に重要だとは思いません。目的は次のとおりです。

1）何が行われているか、何が行われていたかを伝えます。これにより、バグを見つけやすくなり、問題を簡単に元に戻すことができ、プロジェクトをより簡単に維持できるようになります。

2）修正されたチケットがある場合はそれを伝えるため、監査人（会社で使用されている場合、どの変更がどのチケットに対応するかを確認できます）。

最後に、それがすでに修正されている場合、「修正」は意味がありません。それでも作業している場合、「修正済み」は正しくありません。

「修正バグXは」「よりも2つの文字短いバグを修正するX」。
また、「Fixing bug X」よりも3短い。

short-commit-messagesの書き込みの観点から、現在形は時々/通常は数文字を節約しますか？
これは実際には少し重要だと思います。たとえば、Gitが50文字未満の最初のコミットメッセージ行を推奨しています。
また、テキストを少なくします->より速く読み終えましたか？

コミットメッセージは、コミットされるコードを記述した理由を説明します。

「問題3124を修正」、または「問題3124を修正」は、このコードが問題3124を修正|修正することを示しているため、正しいようです。

ただし、文法は、バグを修正済みとしてマークする理由にも依存します。コミット後にバグを修正済みとしてマークできる場合は、「修正済み」で問題ありませんが、コードを確認した後で他のユーザーがバグを修正済みとしてマークする場合は、「修正済み」の方が適切な場合があります。

私はそのような質問に対する最も重要な答えは次のとおりだと思います：誰もが特定のプロジェクトで機能するものを使用し、少なくともほんの少しの一貫性を保つべきです。

現在時制を使用することの利点はわかりますが（実際、オープンソースプロジェクトで現在時制メッセージが表示されたため、この投稿につまずきました）、プロジェクトで現在時制を使用することはないでしょう。これはLinuxとGit、そしておそらく他のより大きなオープンソースプロジェクトに推奨される方法ですが、私がこれらのプロジェクトに参加していない限り、正直言って気にしません。

私はインディーズの開発者であり、リリースノートにはコミットメッセージの最初の行を使用していますが、次の行の説明では、実装の詳細についてのアイデアが得られます。これは、現在時制の開発者ベースのアプローチと比較して、ユーザー中心のワークフローです。この方法で時間を節約できます。ユーザーにリリースノートで指示を与えるのは非常に不自然です。バグを修正し、機能を追加するのが私の仕事です。私はインディーズなので、時間を節約する必要があります。私のチームには「リリースノートライター」がいません。

プロジェクトのルールが既に確立されている場合はそれを使用しますが、実用的であり、作業を簡単または高速にするためのあらゆることを行います。

現在時制を使用する理由が、コミッターが何をしたかではなく、「コミットが何をしているかをより説明的にする」ことである場合"Fixes XXX bug"より"Fix XXX bug"も、より理にかなっていると思います。

それが小さなコミットの場合、私は現在の継続を使用します：

バグ304の修正

または

コメントを追加する

大きなコミットの場合は、変更ログをさらに行います。

• バグ453、657、324を修正
• 式構文の追加
• Operatorクラスをリファクタリングしました。