Gitブランチに名前を付けるためによく使われる慣習の例は何ですか？
私は今、私のグループのCVSリポジトリと相互作用するローカルのgitリポジトリを使っています。私はほぼ神経症的な数の枝を作りました。それらのほとんどはありがたいことに私の体幹に併合しました。しかし、命名が問題になり始めています。単純なラベルで簡単に命名されたタスクを持っていても、それぞれ独自の分岐とマージの状況を含む3つの段階でそれを実行する場合は、そのたびに分岐名を繰り返すことができます。ステージごとに別々の説明を付けて、名前をもっと具体的にすると、ブランチの名前が長くなり扱いにくくなります。
私はここで古いスレッドを通して見ることで、名前の中に/、すなわちトピック/タスク、あるいはそのようなものでブランチに名前を付けることができることを学びました。私はそれをやり始めて、それが物事をよりよく組織化しておくのを助けるかどうか見るかもしれません。
Gitブランチに名前を付けるためのベストプラクティスは何ですか？
編集：実際には誰も命名規則を提案していません。私はそれらが終わったとき私はブランチを削除します。経営陣が常に優先順位を調整しているため、偶然にもいくつかの問題が発生しています。 :)タスクに複数のブランチが必要な理由の例として、タスクの最初の個別のマイルストーンをグループのCVSリポジトリにコミットする必要があるとします。その時点で、私はCVSとの不完全な相互作用のために、そのコミットを実行してからそのブランチをkillします。 （その時点で同じブランチを使い続けようとすると、CVSとのやりとりが多すぎる奇妙さを感じました。）
これが私が使用しているブランチの命名規則とその理由です。
ブランチの命名規則
- ブランチ名の先頭にグループ化トークン（単語）を使用してください。
- ショートリードトークンを定義して使用して、ワークフローにとって意味のある方法でブランチを区別します。
- ブランチ名の一部を区切るにはスラッシュを使用してください。
- 先頭部分として素数を使用しないでください。
- 長命のブランチには、わかりやすい名前を付けないでください。
グループトークン
ブランチ名の前に「グループ化」トークンを使用してください。
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の一部であると決めるかもしれません。たとえば、私のissue trackerはバグに10進数の名前を付けています。混乱を避けるために、私の関連するブランチを単にnnnnnではなくCRnnnnnと名付けます。
$ git checkout CR15032<TAB>
Menu: fix/CR15032 test/CR15032
15032だけを拡張しようとした場合、SHA-1とブランチ名のどちらを検索したいのかgitはよくわからず、私の選択は多少制限されます。
わかりやすい名前は避けてください
長いブランチ名はブランチのリストを見ているとき非常に役に立ちます。しかし、ブランチ名が単一行の大部分を使い果たしてログの表示部分を省略することがあるため、装飾された一行ログを見ると邪魔になることがあります。
一方、長いブランチ名は習慣的に手作業で書き直さないのであれば "マージコミット"でもっと役に立ちます。デフォルトのマージコミットメッセージはMerge branch 'branch-name'です。マージメッセージを単なるMerge branch 'fix/CR15032/crash-when-unformatted-disk-inserted'ではなくMerge branch 'fix/CR15032'として表示すると便利です。
Vincent Driessenによる 成功したGit分岐モデル は良い提案をしています。写真は下です。この分岐モデルが魅力的な場合は、 gitへのフロー拡張 を検討してください。他の人は 流れについてのコメント を持っています
Driessenのモデルは含まれています
マスターブランチ。リリース専用です。一般的な名前は
masterです。そのブランチから「開発」ブランチ。それがほとんどの本線作業に使用されているものです。通称
develop。開発ブランチから複数の機能が分岐します。機能の名前に基づく名前。これらはマスターブランチやリリースブランチではなく、開発にマージされます。
唯一のバグ修正と新機能なしで、候補リリースを入れるためのリリースブランチ。一般的な名前は
rc1.1です。
Hotfixはmasterから来る変更のための短命のブランチであり、開発ブランチを伴わずにmasterに入ります。
私の個人的な好みは、トピックブランチを作成した後にブランチ名を削除することです。
ブランチの意味を説明するためにブランチ名を使用するのではなく、そのブランチの最初のコミットでコミットメッセージの件名行を「Branch：」で開始し、件名が続く場合はメッセージの本文に詳細な説明を含めます。十分なスペースがありません。
私が使用しているブランチ名は、作業中にトピックブランチを参照するための純粋なハンドルです。トピックブランチの作業が終わったら、ブランチ名を取り除きます。後で参照するためにコミットをタグ付けすることもあります。
これはgit branchの出力をより便利にします。長期間のブランチとアクティブなトピックブランチだけをリストします。すべてのブランチをリストするのではありません。
私は私が見てきたそして私が使っている道具に基づいているさまざまな計画から混合してマッチしました。それで私の完成したブランチ名は次のようになります。
名前/機能/課題追跡番号/簡単な説明
これはに変換されます：
マイク/ブログ/ RSSI-12/logo-fix
それらがSourceTreeのフォルダとして解釈されるので、それらは簡単な編成のためにスラッシュで区切られています。問題追跡にJiraを使用しているため、この数を含めるとシステム内での検索が簡単になります。その数を含めることで、プルリクエストを送信しようとしたときにGithub内でその問題を見つけようとしたときにも検索可能になります。
タスクごとに3つの分岐/マージが必要なのはなぜですか？それについてもっと説明してもらえますか。
バグ追跡システムを使用している場合は、ブランチ名の一部としてバグ番号を使用できます。これはブランチ名をユニークに保ちます、そしてそれらを"ResizeWindow-43523"のように、それらを人間が読めるように保つために短くて説明的なWordか2でそれらを前に付けることができます。また、関連するバグを調べることができるので、ブランチを整理するときに物事を簡単にするのに役立ちます。こういうわけで私は私の枝に通常名前を付ける。
これらのブランチは結局masterにマージされるようになっているので、マージした後にそれらを削除しても安全なはずです。あなたが--squashとマージしていない限り、ブランチの全歴史はあなたがそれを必要とするならばまだ存在し続けるでしょう。
Git 2.0の一部である commit e703d7 または commit b6c2a0d （2014年3月）に示すように、別の命名規則があります（ブランチにも適用できます）。
「スペースを使う必要があるときはダッシュを使う」は、スペースを使うべきではないと言う奇妙な方法です。
コマンドラインの説明ではダッシュ複数ワードを使用するのが一般的であるため、これらの場所にスペースを使用することすらしたくないでしょう。
ブランチ名にスペースを入れることはできません（「 ブランチ名内ではどの文字が不正ですか？ 」および git check-ref-formatのmanページ を参照）。
そのため、複数の単語で表現されるブランチの名前には、 '-'（ダッシュ）を区切り文字として使用することをお勧めします。
Farktronixの提案に続いて、MercurialでもJiraのチケット番号を同じように使用してきました。Gitブランチにも引き続き使用する予定です。しかし、チケット番号自体はおそらく十分に一意であると思います。 farktronixが指摘したように、ブランチ名に説明的なWordを含めると便利かもしれませんが、ブランチ間を頻繁に切り替える場合は、おそらく入力する必要が少なくなります。それからあなたがブランチ名を知る必要があるなら、あなたがそれを知らないならばチケットの関連キーワードのためにJiraを見てください。さらに、各コメントにチケット番号を含める必要があります。
ブランチがバージョンを表している場合、ブランチ名にはxxx（例： "1.0.0"）形式を使用し、タグ名にはvx.xx（例 "v1.0.0"）を使用するのが一般的な規則です（競合を避けるため）。 。 gitタグの標準命名規則もあります