web-dev-qa-db-ja.com

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

私は適切なブランチの命名について私のリードとの不一致（もちろん、コーディアル）の真っ最中です。これは、バグ修正と小さな機能ブランチに適用され、長時間実行される機能ブランチには適用されません。実行時間の長い機能ブランチの場合、人間が読める名前の方が良いことに同意します。 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-にどのように適しているかを説明しますが、私が与えた理由は修正/追加できると思います経験的に答えてください。

gitnaminggithubworkflowsbranching
10
Codeman

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

例：

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

チーム名/（53719）-expand-http-parser

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

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

編集：

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

5
dmck

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

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

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

1
Schleis

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

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

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

0
gbjbaanb