3

git commit メッセージがどのように書かれるべきかについて、私はまだ完全に明確ではありません。

私は基本的なルールを知っていますが、これは私を混乱させました。私の実践プロジェクトでは、ログイン システムとユーザー サインアップを作成しましたが、データベースに安全なパスワード ストレージをまだ実装していませんでした。それらはまだソニースタイルのプレーンテキストで保存されていました。コミットメッセージでそれを書き留めたかったのですが、命令でそれをどのように表現するかについて奇妙な困惑に陥っていました。

何かご意見は？

個人的には、これはコミットに含まれていないもののステートメントであっても、コミットメッセージに含める必要があると思います.変化に目を向けます。

4

4 に答える 4

8

コミット メッセージに関する良い記事の 1 つは、 How to Write a Git Commit Messageです。

そのルールの 5 番目は、実際に命令型のムードを使用することを推奨しています。

この命令は少し失礼に聞こえるかもしれません。そのため、あまり使用しません。しかし、git commit の件名には最適です。
この理由の 1 つは、git 自体が、ユーザーに代わってコミットを作成するたびに命令を使用することです。

あなたのトピックの場合、コミットの最初の部分を完了するには、単純な「xxx を追加しません」で十分です (「肯定的なステートメント」、必須)。

于 2014-12-24T23:16:14.167 に答える
3

私はあなたが決定しようとしていると仮定します

 Don't add hashing      #1

また

 Didn't add hashing     #2a
 Doesn't add hashing    #2b

必須です。これは本当に英文法の問題です。しかし、それに答えるには、まず収縮を完全な形に戻す必要があります。

 Do not add hashing        #1
 (It) did not add hashing  #2a
 (It) does not add hashing #2b

これらの最初のものは命令またはコマンドです...ハッシュを追加しないように人々に伝えます。それは不可欠です。

次の 2 つは、コミットに関する事実の単純なステートメントです。彼らは、コミットがハッシュを追加しない、または追加しなかったと言っています。これは誰に対しても指示や命令ではないため、必須ではありません。(「しない」か「しなかった」のどちらかが正しいです。メッセージを書いている人の時間枠で解釈するか、読んでいる人の時間枠で解釈するかによって異なります。)

その分析によると、#1 と #2 の形式は、コミット メッセージで明らかに非常に異なることを意味します。コミット メッセージが実際に何を意味するかを伝えることは、文体の規則や慣習に従うことよりもはるかに重要です。

でも ...

git commit メッセージがどのように書かれるべきかについて、私はまだ完全に明確ではありません。

そのトピックに関する唯一の決定的な権威はありません。私のお勧めは、涙を流さないことです。あなたが正しいと思うことをしてください。人々が不平を言う場合は、あなたが間違ったことを詳しく説明してもらい、学ぶようにしてください. （決して満足できない人もいることに注意してください。）

于 2014-12-25T00:02:12.493 に答える