几个月来，我一直在使用本地 git 存储库与我小组的 CVS 存储库进行交互。我已经制作了几乎神经质的分支，谢天谢地，其中大部分已经合并回我的树干。但是命名开始成为一个问题。如果我有一个任务很容易用一个简单的标签命名，但我分三个阶段完成，每个阶段都包括自己的分支和合并情况，那么我可以每次都重复分支名称，但这会使历史有点混乱。如果我的名称更具体，每个阶段都有单独的描述，那么分支名称开始变得冗长而笨拙。
我确实在这里学习了查看旧线程，我可以开始使用名称中的 / 来命名分支，即主题/任务或类似的东西。我可能会开始这样做，看看它是否有助于更好地组织事情。
命名 git 分支的最佳实践是什么？
编辑：实际上没有人建议任何命名约定。当我完成它们时，我会删除它们。由于管理层不断调整我的优先级，我碰巧有几个。:) 作为一个示例，为什么我可能需要在一个任务上使用多个分支，假设我需要将任务中的第一个离散里程碑提交到组的 CVS 存储库。那时，由于我与 CVS 的交互不完善，我将执行该提交，然后终止该分支。（如果我尝试在那时继续使用相同的分支，我已经看到了与 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/*'
对我来说，斜杠也更适合我的 shell 中的制表符扩展（命令完成）。按照我的配置方式，我可以通过键入部件的第一个字符并按 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/*"
警告：正如斯利普在评论中指出的那样，斜线可能会导致问题。因为分支是作为路径实现的，所以不能有一个名为“foo”的分支和另一个名为“foo/bar”的分支。这可能会让新用户感到困惑。
不要使用裸数字
不要使用裸数字（或十六进制数字）作为分支命名方案的一部分。在引用名称的制表符扩展中，git 可能会确定数字是 sha-1 的一部分，而不是分支名称。例如，我的问题跟踪器使用十进制数字命名错误。我将我的相关分支命名为 CRnnnnn 而不仅仅是 nnnnn 以避免混淆。
$ git checkout CR15032<TAB>
Menu: fix/CR15032 test/CR15032
如果我尝试仅扩展 15032，git 将不确定我是否要搜索 SHA-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。
开发分支的多个功能分支。名称基于功能的名称。这些将被合并回开发，而不是主分支或发布分支。
发布分支来保存候选版本，只有错误修复，没有新功能。典型名称rc1.1。
修补程序是来自 master 的更改的短期分支，将在不涉及开发分支的情况下进入 master。
我混合并匹配了我见过的不同方案，并基于我正在使用的工具。
所以我完成的分支名称将是：
名称/功能/问题跟踪编号/简短描述
这将转化为：
迈克/博客/RSSI-12/logo-fix
这些部分由正斜杠分隔，因为它们在 SourceTree 中被解释为文件夹以便于组织。我们使用 Jira 进行问题跟踪，因此包含该编号可以更轻松地在系统中查找。在尝试提交拉取请求时，在尝试在 Github 中查找该问题时，包括该编号也使其可搜索。
我个人的偏好是在完成主题分支后删除分支名称。
我没有尝试使用分支名称来解释分支的含义，而是在该分支的第一次提交中以“Branch：”开始提交消息的主题行，并在消息正文中包含进一步的解释，如果主题没有给我足够的空间。
我使用的分支名称纯粹是在处理主题分支时引用它的句柄。一旦主题分支的工作结束，我会去掉分支名称，有时会标记提交以供以后参考。
这也使得输出git branch更有用：它只列出长期存在的分支和活动的主题分支，而不是所有分支。
Why does it take three branches/merges for every task? Can you explain more about that?
If you use a bug tracking system you can use the bug number as part of the branch name. This will keep the branch names unique, and you can prefix them with a short and descriptive word or two to keep them human readable, like "ResizeWindow-43523". It also helps make things easier when you go to clean up branches, since you can look up the associated bug. This is how I usually name my branches.
Since these branches are eventually getting merged back into master, you should be safe deleting them after you merge. Unless you're merging with --squash, the entire history of the branch will still exist should you ever need it.
请注意，如提交 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