624

git commitメッセージは、「xのテストを追加する」など、必須の現在形である必要があることを一度読みました。私はいつも過去形を使用していることに気づきます。たとえば、「xのテストを追加しました」など、これは私にとってはるかに自然なことです。

これが最近のJohnResigのコミットで、2つを1つのメッセージに示しています。

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

それは重要ですか？どちらを使うべきですか？

4

7 に答える 7

709

現在形の命令型のコミットメッセージの好みは、Git自体に由来します。GitリポジトリのDocumentation/SubmittingPatchesから：

コードベースに変更を指示するかのように、「[このパッチ]はxyzzyをfrotzにする」や「[I] xyzzyをfrotzに変更する」ではなく、「makexyzzydofrotz」などの命令法の変更を説明します。行動。

そのため、そのスタイルで書かれたGitコミットメッセージがたくさん表示されます。チームやオープンソースソフトウェアで作業している場合は、一貫性を保つために全員がそのスタイルに固執すると便利です。プライベートプロジェクトに取り組んでいて、自分のgit履歴を見ることができるのはあなただけだとしても、他の人と一緒に作業しているときに評価される良い習慣を確立するため、命令法を使用すると便利です。

于 2010-08-27T01:42:01.677 に答える
402

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

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

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

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

この議論は、真に分散されたプロジェクトを扱っている場合に機能します。分散プロジェクトを扱っている場合は、おそらくオープンソースプロジェクトに取り組んでいます。そして、それが実際に配布されている場合、それはおそらく非常に大きなプロジェクトです。実際、それはおそらくLinuxカーネルかGitのどちらかです。LinuxがGitを広め、人気を博した原因である可能性が高いため、人々がそのスタイルを権威と見なす理由は簡単に理解できます。はい、スタイルはこれら2つのプロジェクトで理にかなっています。または、一般的に、大規模なオープンソースの分散プロジェクトで機能します。

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

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

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

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

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

  • 人々は履歴を読んで「このコードベースに何が起こったのか」を知るだけでなく、「このコミットをチェリーピックするとどうなるのか」や「これらのコミットによってコードベースにどのような新しいことが起こるのか」などの質問に答えます。私は将来合併するかもしれないし、しないかもしれない」と語った。

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

  • 通常は短いです

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

  • 課題/機能トラッカーのチケットのタイトルとより一貫性のある名前を付けることができます（過去形は使用しませんが、将来の場合もあります）

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

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

于 2011-11-09T00:59:10.803 に答える
89

私は365gitでより完全な説明を書きました。

命令形の現在形の使用は、少し慣れるのに時間がかかるものです。私がそれについて言及し始めたとき、それは抵抗に遭遇しました。通常、「コミットメッセージは私が行ったことを記録します」という行に沿っています。しかし、Gitは分散バージョン管理システムであり、変更を取得できる場所が潜在的に多くあります。あなたがしたことを伝えるメッセージを書くのではなく、これらのメッセージは、コミットを適用すると何が行われるかについての指示と見なしてください。タイトルでコミットするのではなく：

Renamed the iVars and removed the common prefix.

このようなものを持っている：

Rename the iVars to remove the common prefix

これは、あなたがしたことではなく、コミットを適用することで何ができるかを誰かに伝えます。また、リポジトリの履歴を見ると、Gitで生成されたメッセージもこの時制で書き込まれていることがわかります。「マージ」ではなく「マージ」、「リベース」ではなく「リベース」であるため、同じ時制で書き込むと一貫性が保たれます。最初は奇妙に感じますが、それは理にかなっており（申請時に利用可能な証言）、最終的には自然になります。

そうは言っても、それはあなたのコード、あなたのリポジトリです。それで、あなた自身のガイドラインを設定し、それらに固執してください。

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

于 2011-02-15T13:10:26.407 に答える
40

なぜなら、現在形の命令に固執する

  • 標準があるのは良いことです
  • これは、「何かを実装する」、「何かを修正する」、または「何かをテストする」という形式のバグトラッカーのチケットと一致します。
于 2010-11-30T16:26:07.383 に答える
20

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

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

すなわち要約する：

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

  • メッセージは主にあなた自身（またはあなたのチーム）へのジャーナル/記録としてですが、通常は変化を想定し、何が起こったのかを見つけるために戻って検索するという観点から読んでいます。

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

于 2013-03-29T11:01:24.190 に答える
13

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

于 2010-08-26T22:27:09.530 に答える
10

それはあなた次第です。必要に応じてコミットメッセージを使用してください。ただし、時間と言語を切り替えない方が簡単です。

また、チームで開発する場合は、話し合い、修正する必要があります。

于 2010-08-26T22:24:03.227 に答える