git commitメッセージで過去形または現在形を使用する必要がありますか？[閉まっている]

私は一度読んでいるgitの「xに対してテストを追加」など、メッセージが不可欠現在時制にする必要がありますコミット。私はいつも過去形、たとえば「xの追加テスト」を使用していることに気づきました。

以下は、最近のJohn Resigコミットで、2つのメッセージを1つにまとめたものです。

操作テストでさらにjQueryセットの結果を調整します。予想されるテスト結果の順序も修正しました。

それは重要ですか？どちらを使用すればよいですか？

現在の緊迫した命令型のコミットメッセージの設定は、Git自体から来ています。GitリポジトリのDocumentation / SubmittingPatchesから：

命令ムードの変更を説明します。たとえば、「[このパッチ]はxyzzy do frotzを作成します」または「[I] xyzzyをfrotzに変更しました」ではなく、「コードベースを変更するようにコードベースに命令を与えているかのように」動作。

そのため、そのスタイルで書かれた多くのGit commitメッセージが表示されます。チームまたはオープンソースソフトウェアで作業している場合、一貫性を保つために全員がそのスタイルに固執していると役立ちます。プライベートプロジェクトで作業していて、git履歴を表示するのがあなただけである場合でも、他のユーザーと作業するときに高く評価される良い習慣を確立するため、命令ムードを使用すると役立ちます。

ほとんどの場合、プロジェクトでは過去形を使用する必要があります。いずれの場合でも、プロジェクトは一貫性と明確さのために常に同じ時制を使用する必要があります。

現在形を使用することを主張する他の議論のいくつかは理解しますが、通常は適用されません。以下の箇条書きは、現在形で書くための一般的な議論と私の返答です。

• 現在形で書くことは、あなたがしたことではなく、コミットを適用すると何が起こるかを誰かに伝えます。

これが現在時制を使用したい最も正しい理由ですが、プロジェクトの正しいスタイルでのみです。この考え方では、すべてのコミットをオプションの改善または機能と見なし、特定のリポジトリで保持するコミットと拒否するコミットを自由に決定できます。

この議論は、真に分散したプロジェクトを扱っている場合に有効です。分散プロジェクトを扱っている場合は、おそらくオープンソースプロジェクトで作業しています。そして、実際に配布されている場合、それはおそらく非常に大規模なプロジェクトです。実際、それはおそらくLinuxカーネルかGitのどちらかでしょう。LinuxがGitの普及と普及につながったと考えられるため、人々がそのスタイルを権威と考える理由は簡単に理解できます。はい、この2つのプロジェクトではスタイルが理にかなっています。または、一般に、大規模なオープンソースの分散プロジェクトで動作します。

そうは言っても、ソース管理のほとんどのプロジェクトはこのように機能しません。通常、ほとんどのリポジトリでは正しくありません。これはコミットについての現代的な考え方です。Subversion（SVN）とCVSリポジトリは、このスタイルのリポジトリチェックインをほとんどサポートできませんでした。通常、統合ブランチは不正なチェックインのフィルタリングを処理しましたが、それらは一般に「オプション」または「便利な機能」とは見なされませんでした。

ほとんどのシナリオでは、ソースリポジトリにコミットするときに、この更新で何が変更されたかを説明するジャーナルエントリを作成し、将来、他の人が変更が行われた理由を簡単に理解できるようにします。通常、これはオプションの変更ではありません。プロジェクトの他のユーザーは、プロジェクトをマージまたはリベースする必要があります。あなたは、「私は今日、親愛なる日記のような日記を書いていない会い少年と彼は言います。私にこんにちは」を、代わりにあなたが書く「私が出会った少年を、彼が言った私に挨拶を。」

最後に、このような非分散型プロジェクトの場合、コミットメッセージを読む時間の99.99％は、履歴を読むためのものです。履歴は過去形で読み込まれます。0.01％の確率で、このコミットを適用するか、ブランチ/リポジトリに統合するかを決定します。

• 一貫性。これは、多くのプロジェクト（git自体を含む）での方法です。また、コミットを生成するgitツール（git mergeやgit revertなど）もそれを行います。

いいえ、バージョン管理システムにログインしたことのあるプロジェクトの大部分は過去形で履歴を持っていることを保証します（参照はありませんが、現在形の議論がGit以来新しいことを考えると、おそらく正しいでしょう）。現在形の「改訂」メッセージまたはコミットメッセージは、真に分散したプロジェクトでのみ意味を持ち始めました-上記の最初のポイントを参照してください。

• 人々は「このコードベースに何が起こったか」を知るために履歴を読むだけでなく、「このコミットを選択したときに何が起こるか」、または「これらのコミットのためにコードベースにどのような新しいことが起こるか」などの質問に答えます私は将来合併するかもしれないし、しないかもしれない」

最初のポイントを参照してください。人がコミットメッセージを読む時間の99.99％は、履歴を読むためです。履歴は過去形で読み取られます。0.01％の確率で、このコミットを適用するか、ブランチ/リポジトリに統合するかを決定します。99.99％は0.01％に勝ります。

• 通常はもっと短い

短いので不適切な時制/文法を使用するという良い議論を見たことがありません。標準の50文字のメッセージでは、おそらく平均で3文字しか保存されません。そうは言っても、現在の時制は平均しておそらく数文字短くなります。

• あなたはあなたの問題/機能トラッカーのチケットのタイトルでより一貫してコミットに名前を付けることができます（時々未来ですが過去形を使用しません）

チケットは、現在発生しているもの（このボタンをクリックしたときにアプリが間違った動作を示しているなど）、または将来実行する必要があるもの（テキストは編集者によるレビューが必要など）のいずれかとして記述されます。

履歴（つまり、コミットメッセージ）は、過去に行われたものとして書き込まれます（たとえば、問題が修正されました）。

私は365gitで詳細な説明を書きました。

必須の現在時制の使用は、少し慣れる必要があります。私がそれについて言及し始めたとき、それは抵抗に会いました。通常、「コミットメッセージは私が行ったことを記録します」という流れに沿って表示されます。ただし、Gitは、変更を取得できる場所が多数存在する可能性がある分散バージョン管理システムです。あなたがやったことを伝えるメッセージを書くのではなく、これらのメッセージは、コミットを適用することで何が行われるかを説明するものと考えてください。タイトルでコミットするのではなく：

Renamed the iVars and removed the common prefix.

このようなものがあります：

Rename the iVars to remove the common prefix

これは、あなたがやったことではなく、コミットを適用することで何ができるかを誰かに伝えます。また、リポジトリの履歴を見ると、Gitで生成されたメッセージもこの時制で書かれていることがわかります。最初は奇妙な感じがしますが、それは理にかなっており（申請時に利用可能な推薦状）、最終的には自然になります。

すべてのことを言った-それはあなたのコード、あなたのリポジトリです：それであなた自身のガイドラインをセットアップしてそれらに固執してください。

ただし、この方法をgit rebase -i選択する場合は、rewordオプションを使用することを検討することをお勧めします。

現在の緊迫した命令に固執する

• 標準があるのは良いことです
• これは、「実装」、「修正」、または「何かをテスト」という形式のバグトラッカーのチケットと一致します。

誰のためにメッセージを書いていますか？そして、その読者は通常、所有権の前後にメッセージを読んでいますか？

ここで良い答えが両方の観点から与えられたと思います、私はおそらくすべてのプロジェクトに最良の答えがあることを示唆するだけでは不十分でしょう。分割投票は、多くを示唆するかもしれません。

つまり要約すると：

• メッセージは主に他の人のためのものであり、通常、変更を想定する前のある時点で読んでいます。変更を加えると、既存のコードに対して何が行われるかについての提案。

• 主に自分自身（またはチーム）へのジャーナル/レコードとしてのメッセージですが、通常は変更を想定した観点から読み、何が起こったかを見つけるために検索します。

おそらく、どちらにしても、これがチーム/プロジェクトのモチベーションを導くでしょう。

それは重要ですか？人々は一般に、メッセージを正しく解釈するのに十分賢いですが、そうでなければ、おそらくとにかくリポジトリにアクセスさせないでください！

それはあなた次第です。ちょうどあなたが望むようにコミットメッセージを使用してください。しかし、時間と言語を切り替えない方が簡単です。

そして、あなたがチームで開発する場合-それは議論され、修正されるべきです。