协慌网

现在，我已经使用本地 git 存储库与我的组的 CVS 存储库进行了几个月的交互。我已经制作了一个几乎神经质的分支，其中大部分幸运地合并回我的行李箱。但是命名开始成为一个问题。如果我有一个容易用简单标签命名的任务，但是我在三个阶段完成它，每个阶段都包含它们自己的分支和合并情况，那么我每次都可以重复分支名称，但这会使历史有点混乱。如果我在名称中有更具体的说明，并且每个阶段都有单独的描述，那么分支名称开始变得冗长而且难以处理。

我确实在这里学习通过旧线程查看我可以开始用名称中的 / 来命名分支，即主题 / 任务，或类似的东西。我可能会开始这样做，看看它是否有助于保持更好的组织。

命名 git 分支有哪些最佳实践？

编辑：实际上没有人建议任何命名约定。当我完成分支时，我会删除分支。由于管理层不断调整我的优先事项，我恰巧有几个人。 :) 作为为什么我可能需要在任务上需要多个分支的示例，假设我需要将任务中的第一个离散里程碑提交到组的 CVS 存储库。那时，由于我与 CVS 的不完美交互，我会执行该提交然后杀死该分支。 （如果我在那时尝试继续使用相同的分支，我看到太多奇怪的事情与 CVS 交互。）

以下是我使用的一些分支命名约定及其原因

分支命名约定

1. 在分支名称的开头使用分组令牌（单词）。
2. 定义和使用短引导令牌，以对您的工作流程有意义的方式区分分支。
3. 使用斜杠分隔部分名称。
4. 不要使用裸号作为主要部分。
5. 避免长寿命分支的长描述性名称。

集团代币

在分支名称前面使用 “分组” 标记。

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” 的另一个分支。这可能会让新用户感到困惑。

不要使用裸号码

不要使用裸号（或十六进制数）作为分支命名方案的一部分。在引用名称的制表符扩展内，git 可以决定数字是 sha-1 的一部分而不是分支名称。例如，我的问题跟踪器使用十进制数字命名错误。我将我的相关分支命名为 CRnnnn 而不仅仅是 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 。

修补程序是来自主服务器的更改的短期分支，并且将在不涉及开发分支的情况下进入主服务器。

我个人的偏好是在完成主题分支后删除分支名称。

我没有尝试使用分支名称来解释分支的含义，而是使用 “Branch：” 在该分支的第一次提交中启动提交消息的主题行，如果主题包含在消息正文中的进一步说明不给我足够的空间。

我使用的分支名称纯粹是在处理主题分支时引用主题分支的句柄。一旦完成了主题分支的工作，我就会删除分支名称，有时会标记提交以供以后参考。

这使得git branch的输出也更有用：它只列出了长寿分支和活动主题分支，而不是所有分支。