それで、あなたはあなたの壮大なコミットをする準備ができていますか？もちろん、コードを少し良くしたり、何らかのバグを修正したり、あるいはラインフィードをWindows / Unixスタイルに変更することを決めましたか？ 当然、あなたのコードは完璧であり、あらゆる種類の賞賛に値します！ ブラボー！ あなたのメッセージはあなたの文章にふさわしいですか？ 子孫はあなたが一ヶ月で何をしたかを知ることができますか？ 一年で？ 10年？
- 最初の行は50文字以下で、空行（\ n \ n）で終わる必要があります。 Vimエディターには、構文、自動インデント、およびファイルタイプ用の多くのプラグインがあり、これは非常に簡単に役立ちます。
- .vimrcファイルに次の行を追加して、推奨される72文字への自動改行とスペルをチェックします。
autocmd Filetype gitcommit setlocal spell textwidth=72
- メッセージにフラグを使用しないでください
-m / --message=
, , :
git commit -m "Fix login bug"
:
-m / --message=
, , :
git commit -m "Fix login bug"
:
認証後のユーザーのリダイレクト
chyrius.com/path/to/relevant/card
ユーザーは承認後にホームページにリダイレクトされ、
元のリクエストされたページと認証の違い
フォーム、これは使用するためにいくつかの不便を作成します。
*セッション変数にパスを保存
*認証に成功した後、保存されたパスにリダイレクトする
いくつかの質問に答えてください。
- なぜこの変更が必要なのですか？
この質問は、潜在的なプルリクエストレビューアーに、コミットの中で正確に何が一貫性のない変更を認識しやすくするかを伝えます。
- コミットはどのように問題を解決しますか？
変更を簡単に説明してください：
「検索速度を上げるために赤黒ツリーを実装しました」または「問題<問題の説明>を引き起こした依存パッケージ<such then>を削除しました」。
変更が明らかな場合、この質問はオプションです。
- 変更は副作用を引き起こしますか？
おそらく最も重要な問題の1つは、1つのコミットまたはブランチでの多くの変更の問題を示している可能性があります。 コミットで1つまたは2つの接続された変更、これは正常ですが、5つまたは6つの変更がある場合、コミットが多すぎます:(
あなたとあなたのチームは、単一のコミット/ブランチに適合する変更の数に事前に同意しなければなりません。
メッセージに、プロジェクトのバグ/改善/議論へのリンクを含めてください。 完全なリンクは、単なるバグ番号や議論のトピックの名前よりも便利です。 通常、リンクは3行目の履歴書の後に挿入されます。
プロジェクトのコミットメッセージから真実の物語を得ると、同僚からの仕事に対する敬意を高め、全体的な品質を向上させることができます。
コミットメッセージの新しい標準を設定しようとしたTim Popeに特に感謝します 。
Gitの作成者であり、 優れたコミットメッセージの忠実なサポーターである Linus Torvaldsに感謝します 。 - なぜこの変更が必要なのですか？