☰

What are some examples of commonly used practices for naming git branches? [closed] Ask Question

tag-icon • tag-icon git naming-conventions branch
What are some examples of commonly used practices for naming git branches? [closed] Ask Question

I've been using a local git repository interacting with my group's CVS repository for several months, now. I've made an almost neurotic number of branches, most of which have thankfully merged back into my trunk. But naming is starting to become an issue. If I have a task easily named with a simple label, but I accomplish it in three stages which each include their own branch and merge situation, then I can repeat the branch name each time, but that makes the history a little confusing. If I get more specific in the names, with a separate description for each stage, then the branch names start to get long and unwieldy.

I did learn looking through old threads here that I could start naming branches with a / in the name, i.e., topic/task, or something like that. I may start doing that and seeing if it helps keep things better organized.

What are some best practices for naming git branches?

Edit: Nobody has actually suggested any naming conventions. I do delete branches when I'm done with them. I just happen to have several around due to management constantly adjusting my priorities. :) As an example of why I might need more than one branch on a task, suppose I need to commit the first discrete milestone in the task to the group's CVS repository. At that point, due to my imperfect interaction with CVS, I would perform that commit and then kill that branch. (I've seen too much weirdness interacting with CVS if I try to continue to use the same branch at that point.)

ベストアンサー1

Here are some branch naming conventions that I use and the reasons for them

Branch naming conventions

  1. Use grouping tokens (words) at the beginning of your branch names.
  2. Define and use short lead tokens to differentiate branches in a way that is meaningful to your workflow.
  3. Use slashes to separate parts of your branch names.
  4. Do not use bare numbers as leading parts.
  5. Avoid long descriptive names for long-lived branches.

Group tokens

Use "grouping" tokens in front of your branch names. 

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

The groups can be named whatever you like to match your workflow. I like to use short nouns for mine. Read on for more clarity.

Short well-defined tokens

Choose short tokens so they do not add too much noise to every one of your branch names. I use these:

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

Each of these tokens can be used to tell you to which part of your workflow each branch belongs.

変更の異なるサイクルごとに複数のブランチがあるようですね。サイクルが何なのかはわかりませんが、'new'、'testing'、'verified' だと仮定しましょう。ブランチにこれらのタグの短縮版 (常に同じ綴り) を付けて名前を付けると、ブランチをグループ化して、どの段階にいるのかを思い出すことができます。

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'

おすすめ記事