会社で実施する適切なコミットメッセージテンプレート/ガイドラインを推奨できますか?[閉まっている]


38

Gitでは、適切なコミットテンプレートを設定および実施できます。

会社で実施する適切なコミットテンプレート/ガイドラインを(できれば議論を伴って)推奨できますか?

回答:


42

私が使う

[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.  

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


1
+1それはそれを扱う良い方法であり、変更を簡単にgrepできます。
サルダスリオン

12
ええ!あなたは言論の自由を奪い去った!
CaffGeek

1
Modとの違いを教えてくださいRef。時々、リファクタリングのような小さな修正を行うことがあります。
yegle

2
@yegle Modは、何かを追加したり、動作を変更したり、機能をRef追加したり、APIを追加したりしない内部的なものを変更することです。例:add(Object)関数があり、関数を実装するadd(List<Object>)場合、コメントしModます。その後、私は重複を削除し、直接使用するadd(Object)にはadd(List<Object>)、私が使用しますRef
rangzen

14

以下を使用します。

[JIRAのチケットID]:[メッセージ:実行内容] たとえば-ABC-123:地域ごとにプレゼンテーションを設定する機能が追加されました。

この場合、適切に統合することで、変更/削除/追加されたファイルを課題トラッカーで取得できます。ただし、ABC-123:完了またはABC-123:可能な場合はフィルターで修正するなどのようなことを防ぐ必要があることに注意してください。


バグ修正のための+1ですが、新機能はどうですか?新機能はすべて、同様JIRAで作成されていない限り...
Sardathrion -復活モニカ

3
@Sardathrion-個人的に、JIRAの新機能のトラッカーを作成します。Bugzillaを使用してこれを行い、テストチーム(および他のすべての人)にリリースに投入されるすべてのものの良好な可視性を提供し、テスト/コードレビュー/何でもない場合に発生することを最小限に抑えます。
ジョンホプキンス

@JonHopkins:バグトラッカーは新機能に使用できますが、理想的なツールではない場合があります。もちろん、あなたの走行距離は異なるもの^ _〜
Sardathrion -復活モニカ

3
私はすべてのコミットにチケットが割り当てられるのが大好きになりました(もちろん、いくつかのチケットは複数のコミットを簡単に持つことができます)。これは、後でコードを検査するときに詳細な背景情報を取得する非常に簡単な方法です。「なぜ彼らそれをたのですか?」コミットコメント問題追跡エントリがある場合、回答がはるかに簡単です。
ヨアヒムザウアー

別のブランチでチケットを作成する方が良いと思いませんか?
タマスシェレイ

11

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

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

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

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

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


Gitで長く詳細なコミットメッセージを書く理由はまったくありません。詳細情報は課題トラッカーに記録されるため、私のコミットメッセージは、そのコミットで行った(小さな)変更の1文の説明にすぎません。
マーネンライボウコーサー

9

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

コミットされたものに関する情報を含めるべきではありません。これはscmシステムによって決定できます。より多くのバグ/機能情報は、バグと機能が追跡される場所に属します。

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

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


4
多くのバグツールでは、正しい形式で詳細を入力すると、SCMツールのリビジョンに直接リンクできます。同様に、バグの詳細を正しい形式で入力すると、多くのSCMツールがバグデータベースに直接リンクします。IMO、これを行う限り、あなたは黄金です。
ディーンハーディング

4

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

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


0

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

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

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


0

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

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

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

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

例:
[#452567] [add] [menu_item] new item-guestbook
[#452363] [fix] [banner_top] [WIP] 1024x300を使用できるようになりました
[#452363] [fix] [banner_top] 500x200を使用できるようになりました
[ #452713] [rem] [page]左中央の広告


なぜこれが良いフォーマットだと思うのかを説明すれば、あなたの答えはより強くなるでしょう。この形式の価値は自明かもしれませんが、その価値は他の人には明らかではありません。

コメントのためのおかげで-はい私はすぐに、より詳細に説明します-私はただ事実を開始したい-あなたは:) WIPと答え署名することができると良いのスタック機能だろう
laplasz

「進行中の作業」の場合-これは、あなたが戻って修正するというあなた自身へのメモですか、これでマスターすることをコミットしますか?もしそうなら、なぜですか?
JBRウィルキンソン

CIは、ワークフロー、それを必要とするかもしれない-あなたはできるだけ早くそれを統合するための未完成の変更をマスターするためにプッシュして
laplasz
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.