命名git分支的常用做法有哪些例子？[关闭]

几个月来，我一直在使用本地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的一部分而不是分支名称。例如，我的问题跟踪器使用十进制数字命名错误。为了避免混淆，我将相关分支命名为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。

• 多个功能分支来自开发分支。根据功能名称命名。这些将被合并回developer，而不是master或release分支。

• Release分支用于保存候选版本，仅包含错误修复，没有任何新功能。典型名称rc1.1。

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

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

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

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

这也使输出git branch更加有用：它仅列出长期存在的分支和活动主题分支，而不列出所有分支。

根据我使用的工具，我已经从不同的方案中混合并匹配。
所以我完整的分支名称将是：

名称/功能/问题跟踪号/简短描述

这将转换为：

迈克/博客/ RSSI-12 /徽标修复

这些部分之间用正斜杠分隔，因为这些斜杠在SourceTree中被解释为文件夹，以便于组织。我们使用Jira进行问题跟踪，因此包括数字在内可以更轻松地在系统中查找。当尝试提交请求时，在Github中查找该问题时，包含该数字也可以使其可搜索。

为什么每个任务需要三个分支/合并？您能解释更多吗？

如果使用错误跟踪系统，则可以将错误号用作分支名称的一部分。这样可以使分支名称保持唯一性，并且可以在它们前面加上一两个简短的描述性单词，以使它们易于阅读，例如"ResizeWindow-43523"。由于您可以查找关联的错误，因此在清理分支时还可以使事情变得更容易。这就是我通常命名分支的方式。

由于这些分支最终将合并回master，因此合并后应该安全删除它们。除非您要合并，否则在您需要时--squash分支的整个历史将仍然存在。

请注意，如commit e703d7或commit b6c2a0d （2014年3月）所示（现已成为Git 2.0的一部分），您将找到另一种命名约定（可应用于分支）。

“当您需要使用空间时，请使用破折号”是一种奇怪的说法，您不能使用空间。
因为在命令行描述中多用破折号很常见，所以您甚至都不希望在这些地方使用空格。

分支名称不能有空格（请参见“ 分支名称中哪些字符是非法的？ ”和git check-ref-format手册页）。

因此，对于将由多词表达式表示的每个分支名称，使用' -'（破折号）作为分隔符是一个好主意。

遵循farktronix的建议，我们一直在将Jira票号用于类似的商品，并且我打算继续将其用于git分支。但是我认为票号本身可能足够独特。正如farktronix指出的那样，在分支名称中使用描述性词可能会有所帮助，但如果您经常在分支之间进行切换，则可能希望键入的次数更少。然后，如果您需要知道分支名称，请在Jira中查找故障单中的关联关键字（如果您不知道）。此外，您应该在每个评论中包含票证编号。

如果您的分支代表一个版本，则似乎通用约定是对分支名称使用xxx（例如：“ 1.0.0”）格式，对标记名称使用vx.xx（例如“ v1.0.0”）（以避免冲突） 。另请参阅：git标签有一个标准的命名约定