What are some examples of commonly used practices for naming git branches?
我已经使用一个本地Git存储库与我的小组的cvs存储库进行交互几个月了。我已经做了很多几乎神经质的枝条，其中大部分谢天谢地又回到了我的树干里。但是命名开始成为一个问题。如果我有一个任务很容易用一个简单的标签命名，但是我分三个阶段完成它，每个阶段包括自己的分支和合并情况，那么我可以每次重复分支名称，但是这会使历史有点混乱。如果我在名称中有更具体的描述，每个阶段都有一个单独的描述，那么分支名称就会变得冗长和笨拙。
我确实从这里了解到，我可以开始用名称/来命名分支，例如主题/任务或类似的东西。我可能会开始这样做，看看它是否有助于更好地组织事情。
命名Git分支的最佳实践是什么？
编辑：实际上没有人提出任何命名约定。完成分支后，我会删除它们。由于管理层不断调整我的工作重点，我正好有几个人在身边。：)作为为什么我可能需要一个任务上的多个分支的一个例子，假设我需要将任务中的第一个离散里程碑提交到组的CVS存储库中。在那一点上，由于我与CVS的交互不完善，我将执行该提交，然后杀死该分支。(如果我继续使用同一个分支，我会看到太多与cvs交互的奇怪。)
下面是我使用的一些分支命名约定及其原因
分支命名约定
群令牌
在分支名称前面使用"分组"标记。
1 2 3 4 5 6 | group1/foo group2/foo group1/bar group2/bar group3/bar group1/baz |
这些组可以根据您的工作流程进行命名。我喜欢用短名词。请继续阅读以了解更多信息。
定义明确的短令牌
选择短标记，这样它们就不会给每个分支名称添加太多干扰。我用这些：
1 2 3 4 | 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 |
这些令牌中的每一个都可以用来告诉您每个分支属于工作流的哪个部分。
听起来，对于不同的变化周期，您有多个分支。我不知道你的周期是什么，但是假设它们是"新的"、"测试的"和"验证的"。您可以用这些标记的缩写版本命名分支，它们的拼写方式总是相同的，可以对它们进行分组并提醒您所处的阶段。
1 2 3 4 5 6 | new/frabnotz new/foo new/bar test/foo test/frabnotz ver/foo |
您可以快速判断哪些分支已经到达了每个不同的阶段，并且可以使用git的模式匹配选项轻松地将它们组合在一起。
1 2 3 4 5 6 7 8 9 10 | $ git branch --list"test/*" test/foo test/frabnotz $ git branch --list"*/foo" new/foo test/foo ver/foo $ gitk --branches="*/foo" |
使用斜线分隔部件
您可以在分支名称中使用您最喜欢的任何分隔符，但我发现斜线是最灵活的。您可能更喜欢使用破折号或点。但是斜线允许您在推送或从远程服务器获取数据时进行一些分支重命名。
1 2 | $ git push origin 'refs/heads/feature/*:refs/heads/phord/feat/*' $ git push origin 'refs/heads/bug/*:refs/heads/review/bugfix/*' |
对于我来说，斜线对于shell中的选项卡扩展(命令完成)也更有效。我配置它的方式是，通过键入部件的第一个字符并按Tab键，可以搜索具有不同子部件的分支。然后zsh给了我一个与我输入的令牌部分匹配的分支列表。这适用于前面的令牌以及嵌入的令牌。
1 2 3 4 5 6 | $ git checkout new<TAB> Menu: new/frabnotz new/foo new/bar $ git checkout foo<TAB> Menu: new/foo test/foo ver/foo |
(zshell对于命令完成是非常可配置的，我也可以配置它以同样的方式处理破折号、下划线或点。但我选择不去。)
它还允许您在许多git命令中搜索分支，如下所示：
1 2 3 | git branch --list"feature/*" git log --graph --oneline --decorate --branches="feature/*" gitk --branches="feature/*" |
警告：正如Slip在评论中指出的那样，斜线会导致问题。因为分支是作为路径实现的，所以不能有一个名为"foo"的分支和另一个名为"foo/bar"的分支。对于新用户来说，这可能会令人困惑。
不要使用裸数字
不要使用裸数字(或十六进制数字)作为分支命名方案的一部分。在引用名称的制表扩展中，Git可以决定数字是sha-1的一部分，而不是分支名称。例如，我的问题跟踪程序用十进制数字命名错误。我把我的相关分支命名为crnnnnn，而不仅仅是nnnnn，以避免混淆。
1 2 | $ git checkout CR15032<TAB> Menu: fix/CR15032 test/CR15032 |
如果我尝试只扩展15032，Git将无法确定我是要搜索sha-1还是要搜索分支名称，而且我的选择将受到一定限制。
避免使用长描述性名称
当您查看分支列表时，长分支名称非常有用。但在查看装饰过的单行日志时，它可能会遇到障碍，因为分支名称会占用大部分单行并缩写日志的可见部分。
另一方面，如果您不习惯用手重写分支名称，那么长分支名称在"合并提交"中会更有用。默认的合并提交消息是
Vincent Driessen提出的一个成功的Git分支模型具有很好的建议。下面是一张图片。如果这个分支模型需要考虑到Git的流扩展。其他人评论了流量
Driessen的模型包括
主分支，仅用于发布。典型名称
master 。该分支的"开发"分支。这是最主要的主线工作。俗称
develop 。开发分支的多个功能分支。基于功能名称的名称。这些将被重新合并到开发中，而不是合并到主分支或发布分支中。
发布分支以保存候选版本，只包含错误修复，没有新功能。典型名称
rc1.1 。
热修复程序是从master进行的更改的短期分支，将在不涉及开发分支的情况下进入master。
我个人的偏好是在完成主题分支之后删除分支名称。
我没有试图使用分支名称来解释分支的含义，而是在该分支的第一次提交时用"branch:"开始提交消息的主题行，如果主题没有给我足够的空间，则在消息正文中包含进一步的解释。
我使用的分支名称纯粹是一个句柄，用于在处理主题分支时引用它。一旦主题分支的工作结束，我就去掉分支名称，有时标记提交以供以后参考。
这使得
我混合和匹配了我见过的不同的方案，并基于我使用的工具。所以我完成的分支名称是：
name/feature/issue-tracker-number/short-description
这将转化为：
mike/blogs/RSSI-12/logo-fix
这些部分由正斜杠分隔，因为这些部分在SourceTree中被解释为便于组织的文件夹。我们使用JIRA进行问题跟踪，因此包括数字可以更容易地在系统中查找。当试图在GitHub中查找请求请求请求时，包括该数字也使其可搜索。
为什么每个任务需要三个分支/合并？你能详细解释一下吗？
如果使用bug跟踪系统，可以将bug编号作为分支名称的一部分。这将保持分支名称的唯一性，您可以在它们前面加上一个或两个简短的描述性单词，以保持它们的可读性，如
因为这些分支最终会被合并回master，所以在合并之后应该可以安全地删除它们。除非你和
注意，如commit e703d7或commit b6c2a0d(2014年3月)所示，现在是git 2.0的一部分，您将发现另一个命名约定(可以应用于分支)。
"When you need to use space, use dash" is a strange way to say that you must not use a space.
Because it is more common for the command line descriptions to use dashed-multi-words, you do not even want to use spaces in these places.
分支名称不能有空格(请参阅"分支名称中哪些字符非法？"和
因此，对于将由多单词表达式表示的每个分支名称，使用"EDOCX1"(破折号)作为分隔符是一个好主意。
根据Farktronix的建议，我们已经在Mercurial中使用类似的jira票据编号，我计划继续在Git分支机构中使用它们。但我认为机票号码本身可能是独一无二的。正如Farktronix所指出的，在分支名称中使用描述性单词可能会有所帮助，但如果您经常在分支之间切换，则可能不需要键入。然后，如果你需要知道分支名称，如果你不知道的话，可以在jira中查找与之相关联的关键字。此外，您应该在每个注释中包括票据编号。
如果您的分支代表一个版本，那么通常的约定是对分支名称使用x.x.x(示例："1.0.0")格式，对标记名称使用vx.x.x(示例"v1.0.0")(以避免冲突)。另请参见：是否有Git标记的标准命名约定