git分支命名最佳实践
现在，我已经使用了一个本地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/*"
警告：正如Slipp在评论中指出的那样，斜杠可能会导致问题。 因为分支被实现为路径，所以不能有名为“foo”的分支和名为“foo / bar”的另一分支。 这可能会让新用户感到困惑。
不要使用裸数字
不要使用裸号码（或十六进制数字）作为分支命名方案的一部分。 在引用名称的tab扩展中，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' 。
文森特Driessen成功的Git分支模型有很好的建议。 下面是一张照片。 如果这个分支模型吸引你考虑流扩展到git。 其他人评论流量
Driessen的模型包括
主分支，仅用于发布。 典型的名字master 。
该分支的“发展”分支。 这是大多数主线工作所使用的。 典型的名字devel 。
开发分支的多个功能分支。 名称基于功能的名称。 这些将被合并回开发，而不是进入主或分支分支。
发布分支以容纳候选版本，只有错误修复并且没有新功能。 典型名称rc1.1 。
修补程序是来自主服务器的变更的短期分支，如果不涉及开发分支，它将进入主服务器。
我的个人偏好是在完成主题分支后删除分支名称。
我没有试图用分支名称来解释分支的含义，而是使用“Branch：”在该分支的第一次提交中启动提交消息的主题行，并在消息正文中包含进一步的解释，如果主题没有给我足够的空间。
我使用的分支名称纯粹是在处理它时引用主题分支的句柄。 一旦主题分支的工作结束，我就摆脱了分支名称，有时会标记提交以供日后参考。
这使得git branch的输出也更加有用：它只列出长期分支和活动主题分支，而不是所有分支。