gitブランチに名前を付けるために一般的に使用されるプラクティスの例は何ですか？[閉まっている]

私は今、グループのCVSリポジトリと対話するローカルgitリポジトリを数か月使用しています。私はほとんど神経質な数の枝を作りました、そのほとんどはありがたいことに私の幹に戻ってマージしました。しかし、ネーミングが問題になり始めています。単純なラベルで簡単に名前を付けるタスクがあるが、それぞれ独自のブランチとマージの状況を含む3つの段階でそれを達成する場合、ブランチ名を毎回繰り返すことができますが、履歴が少し混乱します。ステージごとに別々の説明を付けて、名前をより具体的にすると、ブランチ名が長くなり、扱いにくくなります。

ここで古いスレッドを調べて、ブランチに名前の/を付けて開始できることを学びました。つまり、トピック/タスク、またはそのようなものです。私はそれを始めて、それが物事をよりよく整理するのを助けるのに役立つかどうか見てみるかもしれません。

gitブランチに名前を付けるためのいくつかのベストプラクティスは何ですか？

編集：実際に命名規則を提案した人はいません。ブランチを使い終わったら、ブランチを削除します。経営陣が常に私の優先順位を調整しているため、たまたまいくつかあるだけです。:)タスクに複数のブランチが必要になる理由の例として、タスクの最初の個別のマイルストーンをグループのCVSリポジトリにコミットする必要があるとします。その時点で、CVSとの対話が不完全なため、そのコミットを実行してから、そのブランチを強制終了しました。（その時点で同じブランチを使い続けようとすると、CVSとのやり取りがおかしくなるのがわかりました。）

ここに私が使用するいくつかのブランチ命名規則とその理由があります

ブランチの命名規則

1. ブランチ名の最初にグループ化トークン（単語）を使用します。
2. 短いリードトークンを定義して使用し、ワークフローにとって意味のある方法でブランチを区別します。
3. ブランチ名の一部を区切るにはスラッシュを使用します。
4. 先頭部分として裸の数字を使用しないでください。
5. 存続期間の長いブランチには、説明的な長い名前を付けないでください。

グループトークン

ブランチ名の前に「グループ化」トークンを使用します。

group1/foo
group2/foo
group1/bar
group2/bar
group3/bar
group1/baz

グループには、ワークフローに合わせて好きな名前を付けることができます。私は短い名詞を使うのが好きです。より明確にするために読んでください。

短く明確なトークン

短いトークンを選択して、すべてのブランチ名に過度のノイズを加えないようにします。私はこれらを使用します：

wip       Works in progress; stuff I know won't be finished soon
feat      Feature I'm adding or expanding
bug       Bug fix or experiment
junk      Throwaway branch created to experiment

これらのトークンのそれぞれを使用して、各ブランチがワークフローのどの部分に属しているかを通知できます。

変更のサイクルごとに複数のブランチがあるようです。私はあなたのサイクルが何であるかはわかりませんが、それらが「新規」、「テスト」、「検証済み」であると仮定しましょう。これらのタグの省略形を使用してブランチに名前を付けることができます。常に同じ方法でつづられ、ブランチをグループ化し、どの段階にいるかを通知します。

new/frabnotz
new/foo
new/bar
test/foo
test/frabnotz
ver/foo

どのブランチが各ステージに到達したかをすばやく確認でき、Gitのパターンマッチングオプションを使用して簡単にグループ化できます。

$ git branch --list "test/*"
test/foo
test/frabnotz

$ git branch --list "*/foo"
new/foo
test/foo
ver/foo

$ gitk --branches="*/foo"

スラッシュを使用してパーツを分離する

ブランチ名には好きなデリミタを使用できますが、スラッシュが最も柔軟であると思います。ダッシュまたはドットを使用することをお勧めします。ただし、スラッシュを使用すると、リモートへのプッシュまたはリモートからのフェッチ時にブランチの名前を変更できます。

$ git push origin 'refs/heads/feature/*:refs/heads/phord/feat/*'
$ git push origin 'refs/heads/bug/*:refs/heads/review/bugfix/*'

私にとって、スラッシュは私のシェルでのタブ拡張（コマンド補完）にも適しています。構成方法では、パーツの最初の文字を入力してTabキーを押すことで、異なるサブパーツを持つブランチを検索できます。次にZshは、入力したトークンの一部と一致するブランチのリストを表示します。これは、先行するトークンおよび埋め込まれたトークンに対して機能します。

$ git checkout new<TAB>
Menu:  new/frabnotz   new/foo   new/bar


$ git checkout foo<TAB>
Menu:  new/foo   test/foo   ver/foo

（Zshellはコマンド補完について非常に構成可能であり、ダッシュ、アンダースコア、またはドットを同じ方法で処理するように構成することもできます。ただし、そうしないことを選択します。）

次のように、多くのgitコマンドでブランチを検索することもできます。

git branch --list "feature/*"
git log --graph --oneline --decorate --branches="feature/*" 
gitk --branches="feature/*" 

警告：Slippがコメントで指摘しているように、スラッシュは問題を引き起こす可能性があります。ブランチはパスとして実装されるため、「foo」という名前のブランチと「foo / bar」という名前の別のブランチを作成することはできません。これは、新しいユーザーを混乱させる可能性があります。

裸の数字は使用しないでください

ブランチの命名体系の一部として裸の番号（または16進数）を使用しないでください。参照名のタブ展開内では、gitは数値がブランチ名ではなくsha-1の一部であると判断する場合があります。たとえば、私の問題追跡システムでは、バグに10進数で名前を付けています。混乱を避けるために、関連するブランチに単にnnnnnではなくCRnnnnnという名前を付けます。

$ git checkout CR15032<TAB>
Menu:   fix/CR15032    test/CR15032

15032だけを拡張しようとした場合、gitはSHA-1を検索するのかブランチ名を検索するのかわからず、私の選択は多少制限されます。

長い説明的な名前は避けてください

長いブランチ名は、ブランチのリストを見ているときに非常に役立ちます。ただし、装飾された1行のログを見ると、ブランチ名が1行のほとんどを消費し、ログの表示部分を省略できるため、邪魔になることがあります。

一方、手作業で習慣的に書き直さない場合、長いブランチ名は「マージコミット」でより役立ちます。デフォルトのマージコミットメッセージはMerge branch 'branch-name'です。マージメッセージMerge branch 'fix/CR15032/crash-when-unformatted-disk-inserted'を単にの代わりに表示する方が便利な場合がありますMerge branch 'fix/CR15032'。

Vincent Driessenによる成功したGit分岐モデルには、良い提案があります。写真は下にあります。この分岐モデルが魅力的な場合は、gitのフロー拡張を検討してください。他の人がフローについてコメントしています

Driessenのモデルには、

• リリースのみに使用されるマスターブランチ。典型的な名前master。

• そのブランチからの「開発」ブランチ。これは、ほとんどのメインライン作業に使用されるものです。通称develop。

• 複数の機能は、開発ブランチから分岐します。機能の名前に基づく名前。これらは、masterまたはreleaseブランチではなく、developにマージされます。

• バグ修正のみを含み、新機能を含まない、候補リリースを保持するリリースブランチ。典型的な名前rc1.1。

修正プログラムは、マスターからの変更の短命のブランチであり、開発ブランチが関与せずにマスターに移行します。

私の個人的な好みは、トピックブランチが終了したらブランチ名を削除することです。

ブランチの名前を使用してブランチの意味を説明する代わりに、そのブランチの最初のコミットでコミットメッセージの件名を「Branch：」で開始し、件名が十分なスペースがありません。

私が使用しているブランチ名は、トピックブランチで作業しているときにトピックブランチを参照するための純粋なハンドルです。トピックブランチでの作業が終了したら、ブランチ名を削除し、後で参照できるようにコミットにタグを付けます。

これにより、の出力もgit branchさらに便利になります。すべてのブランチではなく、長期間有効なブランチとアクティブなトピックブランチのみが一覧表示されます。

私はこれまでに見たさまざまなスキームを組み合わせて使用​​しており、使用しているツールに基づいています。
だから私の完成したブランチ名は次のようになります：

名前/機能/ issue-tracker-number / short-description

これは次のように変換されます：

mike / blogs / RSSI-12 / logo-fix

パーツは、スラッシュで区切られています。これは、それらがSourceTree内のフォルダーとして解釈され、整理が容易になるためです。課題追跡にはJiraを使用しているため、番号を含めると、システムを簡単に検索できます。その番号を含めると、プルリクエストを送信しようとしたときにGithub内でその問題を見つけようとしたときに検索可能になります。

タスクごとに3つのブランチ/マージが必要なのはなぜですか？それについてもっと説明できますか？

バグ追跡システムを使用している場合は、ブランチ番号の一部としてバグ番号を使用できます。これにより、ブランチ名が一意に保たれ、のように短くてわかりやすい単語をプレフィックスとして付けて、人間が読めるようにすることができます"ResizeWindow-43523"。また、関連するバグを調べることができるので、ブランチをクリーンアップするときに物事が簡単になります。これは通常、ブランチに名前を付ける方法です。

これらのブランチは最終的にマスターにマージされるため、マージ後にブランチを削除しても安全です。とマージしているのでない限り--squash、ブランチが必要になった場合でも、ブランチの履歴はすべて残っています。

コミットe703d7またはコミットb6c2a0d （2014年3月）に示されているように、Git 2.0の一部となったため、別の命名規則（ブランチに適用できる）があることに注意してください。

「スペースを使いたいときはダッシュを使う」というのはスペースを使ってはいけないというおかしな言い方です。
コマンドラインの説明では破線のマルチワードを使用する方が一般的であるため、これらの場所でスペースを使用する必要はありません。

ブランチ名にスペースを含めることはできません（「ブランチ名内で不正な文字は？」およびgit check-ref-formatマニュアルページを参照）。

したがって、複数単語の式で表されるすべてのブランチ名について-、区切り文字として' '（ダッシュ）を使用することをお勧めします。

farktronixの提案に従って、私たちは同様にmercurialでJiraチケット番号を使用してきましたが、私はそれらをgitブランチで引き続き使用することを計画しています。しかし、チケット番号自体はおそらく十分にユニークだと思います。farktronixが指摘しているように、ブランチ名に説明的な単語を含めると役立つ場合がありますが、ブランチ間を頻繁に切り替える場合は、タイプする回数を少なくする必要があります。次に、ブランチ名を知る必要がある場合、知らない場合はJiraでチケットの関連キーワードを探します。さらに、各コメントにはチケット番号を含める必要があります。

ブランチがバージョンを表す場合、一般的な規則はブランチ名にxxx（例： "1.0.0"）形式を使用し、タグ名にvx.xx（例 "v1.0.0"）形式を使用することです（競合を回避するため）。 。参照：is-there-an-standard-naming-convention-for-git-tags