web-dev-qa-db-ja.com

会社に適用する適切なコミットメッセージテンプレート/ガイドラインを推奨できますか？

Gitでは、適切なコミットテンプレートを設定して適用できます。

会社に適用するための適切なコミットテンプレート/ガイドラインを（できれば議論とともに）推奨できますか？

version-controlgitdvcs
38
kyrisu

私が使う

[Abc]: Message.

Add、Mod（ify）、Ref（actoring）、Fix、Rem（ove）、Rea（dability）を使用すると、ログファイルを簡単に抽出できます。

例：

Add: New function to rule the world.  
Mod: Add women factor in Domination.ruleTheWorld().  
Ref: Extract empathy stuff to an abstract class.  
Fix: RUL-42 or #42 Starvation need to be initialised before Energy to avoid the nullpointer in People.  
Rem: freeSpeech is not used anymore.  
Rea: Removed old TODO and extra space in header.

行が複数ある場合は、最も重要なものから順に並べ替えます。

42
rangzen

以下を使用します。

[JIRAのチケットID]：[メッセージ：何が行われたか]例-ABC-123：リージョンごとにプレゼンテーションを設定する機能が追加されました。

この場合、適切に統合すると、課題追跡で変更/削除/追加されたファイルを取得できます。ただし、可能であれば、フィルターを使用してABC-123：DoneまたはABC-123：Fixedのようなものを防止する必要があることに注意してください。

14
Andrey Taptunov

単純なルールが1つあります。これは、多くの（すべてではないにしても）SCMとSCMで動作するほとんどのツールが従う規則です。

コミットメッセージの最初の行は短い要約ですが、メッセージの残りの部分には詳細が含まれています。

したがって、ほとんどのツールは最初の行のみを表示し、メッセージ全体をオンデマンドで表示します。

コミットメッセージの典型的な誤用は、変更の箇条書きリストです（最初の箇条書きのみが表示されます）。もう1つの誤用は、詳細なメッセージを1行で書くことです。

したがって、強制することが1つある場合、それは最初の行の最大長です。

11
barjak

個人的には、使う価値のある一般的なコミットテンプレートを見たことがありません。コメントはコミットが何に関連しているかを簡潔に述べるべきです。どの機能/バグ修正か、なぜ変更が行われたかについての簡単な説明。

コミットされた情報は含めないでください。これはscmシステムによって決定できます。より多くのバグ/機能情報は、これまでにバグや機能が追跡されている場所に属しています。

コミット後にバグレポートを更新するときは、バグレポートのコメントとともにコミットリビジョンも記載するとよいと思います。このようにして、コミットコメントからバグレポートまでの方法を見つけることができます。また、バグレポートのコメントごとにコミットされた内容を見つけることができますが、バグレポートとコミットメッセージの両方に情報を置くことで情報を複製することはありません。

次に、ファイルのリビジョンの履歴を表示すると、履歴を説明する簡潔なメッセージが表示されますが、詳細なバグレポートや詳細についてはタスクの説明を探す場所もわかります。

9
Alb

Gitでは Gitフック を使用してほぼすべてを強制できます。アイデアについては、.git/hooksの例を確認してください。

メッセージに関しては、非常に一般的なケースでは、解決しようとしていた問題とソリューション自体について十分な情報を含め、後でこのコミットを見つけて特定できるようにする必要があります。ほとんどの場合、問題はバグ番号を参照します（バグ追跡システムと適切に統合されている場合）。プロセスが統合する他のシステム（コードレビュー追跡システムなど）がある場合は、適切なビットも含めます。

Extracted checking foobar range from bar() into foo(min, max) to re-use
in yadda() and blah(). foo() returns true if foobar is in the
specified range and false otherwise.

BugID: 123456
ReviewedBy: mabuddy
AutomergeTo: none

しかし、あなたはそれをシンプルに保ちたいです。そうでなければ、人々はシステムをだまして、役に立たないコミットメッセージを生成する方法を見つけるでしょう。

4
user15258

通常、私が使用するチケット追跡システムにあるID、または最初の行として高レベルの概要を持っています。次に、コミットの特定の変更について、「箇条書き」の項目を示します。だから私は次のようなことができます：

MyVideoGameProject-123 OR Inventory System Improvements
Made inventory GUI drap and drap
Added ability to have multiple bag slots to expand inventory capacity

これは、私が気に入っている最もクリーンなコミット形式です。それは直接的かつ要旨です。私がこの方法で行うもう1つの理由は、変更ログを作成する場合、すべてのコミットメッセージを取得して、変更ログに簡単に解析できることです。

0
ryanzec

以下を含むテンプレートを使用します

  • バグ/機能/修正のID番号
  • コードがテストされているかどうかを示すはい/いいえ
  • そしてコミットの意図の簡単な説明のための詳細セクション

ただし、最初の2つはほとんどの場合省略される（たまに3つすべて）ので、それほど大したことではありません。

0
Nobody

[ticketId] [ABC] [topicId] [WIP]メッセージ。ここで、

  • ticketId-タスクリポジトリ内のアイテムのID
  • ABC-追加（機能）、修正（バグ修正）、str（構造）、dep（依存関係）rem（後方非互換性/削除）、rea（読みやすさ）、ref（リファクタリング）
  • topicId-ジェンキンのジョブセレクター、ブランチ名、および/またはgerritのトピック名にすることができます
  • WIP-進行中/未処理（つまり、継続的インテグレーションではこれが必要になる場合があります）
  • メッセージ-変更の詳細

例：
[＃452567] [追加] [menu_item]新しいアイテム-ゲストブック
[＃452363] [fix] [banner_top] [WIP] 1024x300を使用できるようになりました
[＃452363] [fix] [banner_top] 500x200を使用できるようになりました
[＃452713] [rem] [page]左中央の広告

0
laplasz