小さなバグ修正と小さな機能のどちらが良いですか-チケット番号でブランチに名前を付けるか、機能の説明でブランチに名前を付けますか？

私は適切なブランチの命名について私のリードとの不一致（もちろん、コーディアル）の真っ最中です。これは、バグ修正と小さな機能ブランチに適用され、長時間実行される機能ブランチには適用されません。長期間実行される機能ブランチの場合、人間が読める名前の方が優れていることに同意します。2つの視点があります。

私の：

チームとチケット番号に従ってブランチに名前を付けた方が良いです。チケットシステムでそれらを見つけやすくなり、入力が短くなります。また、チケットに関する履歴情報を検索するときに、GITで関連するブランチを簡単に検索できます。

例：

team-name/12345
team-name/53719

彼：

機能/機能に従ってブランチに名前を付けます。オートコンプリートが簡単になり、個々の数字より覚えやすくなります。

例：

team-name/fix-that-sql-bug
team-name/expand-http-parser

私が提供した1つの妥協点は次のとおりです。

team-name/12345-fix-that-sql-bug

しかし、GITのオートコンプリートに干渉するため、彼はこれを好みません。

これが主に意見に基づいている場合は、これがどのようにSOに適しているかについてのガイダンスを遠慮なく教えてください。

この場合、番号と説明の両方を含む命名規則で妥協できる可能性があります。

例：

チーム名/（12345）-fix-that-sql-bug

チーム名/（53719）-展開-http-パーサー

ここには正解はありません。あなたの視点によっては主観的なものです。

しかし、もしあなたが両方を妥協すれば、あなたは両方の世界のベストを手に入れます。チームで同様の意見の相違がある場合は、このことを心に留めておいてください。

編集：

オートコンプリートの問題に対処するには、番号付きIDを角かっこで囲みます。これにより、ブランチを入力するときに常に入力する（ブランチを表示する）ことができます。このリストから、番号付きIDと説明を確認できます。数個の数字、タブを入力するだけで、

誰もが同意して理解できる一貫したシステムがある限り、それは本当に問題ではありません。

ただし、チケット番号で移動すると、どのブランチで作業するかを覚えやすくなります。説明ではなく、問題番号に直接結びついているため。説明だけを行うと、どの特定の問題が想定されているかを思い出すことがより困難になり、漠然となるのを避けようとすると長続きする可能性があります。

team-name/bug-that-has-specific-circumstances-to-occur-and-takes-alot-to-describe

オートコンプリートを利用するためだけに名前を付けるのはばかげています。

バグトラッカーへのリンクは重要です（いくつかの単語では解決されない、ブランチによって解決される問題を正確に定義しているため、適切な名前よりも重要です）が、同時に、ユーザーに期待するのはユーザビリティの失敗ですバグ＃7312と＃7213の違いを知る。また、人々が毎回完全に正しい数値を取得することを期待するのは失敗です-ある日、7313の7312を誤読/誤入力したため、誰かが間違ったブランチにコミットします。（私のチームの誰かが今日やった！）

両方を行う-ブランチに番号を付け、チェックとして機能するように非常に短いテキストの説明を追加します。私は最初に番号を付けます-とにかくブランチのテキストを知る必要があるので、オートコンプリートは非難されます（たとえば、「bug-fix-for-server」または「fix-bug-for-server」-あなたはまだ知る必要がありますfまたはbで始まる場合！）