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

Question

关闭。 这个问题是基于意见的。 它目前不接受答案。

---

想改善这个问题吗？ 更新问题，以便通过编辑这篇文章用事实和引文来回答问题。

5年前关闭。

改进这个问题

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

我确实在这里学习了查看旧线程，我可以开始在名称中使用 / 命名分支，即主题/任务，或类似的东西。 我可能会开始这样做，看看它是否有助于让事情更有条理。

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

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

Answer 1

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

分支命名约定

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' 。

Answer 2

Vincent Driessen 的一个成功的 Git 分支模型有很好的建议。 下面是一张图片。 如果此分支模型吸引您，请考虑将流扩展到 git 。 其他人 评论了流量

Driessen 的模型包括

• 一个主分支，仅用于发布。 典型的名字master 。

• 该分支的“开发”分支。 这是用于大多数主线工作的一种。 俗称develop 。

• 开发分支的多个功能分支。 基于特征名称的名称。 这些将被合并回开发，而不是主分支或发布分支。

• 发布分支来保存候选版本，只有错误修复，没有新功能。 典型名称rc1.1 。

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

Answer 3

我根据我使用的工具混合和匹配了我见过的不同方案。
所以我完成的分支名称将是：

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

这将转化为：

迈克/博客/RSSI-12/logo-fix

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

Answer 4

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

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

我使用的分支名称纯粹是用于在处理主题分支时引用该分支的句柄。 一旦主题分支的工作结束，我就会去掉分支名称，有时会标记提交以供以后参考。

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

Answer 5

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

如果您使用错误跟踪系统，您可以使用错误编号作为分支名称的一部分。 这将保持分支名称的唯一性，您可以在它们"ResizeWindow-43523"两个简短的描述性单词，以保持它们的可读性，例如"ResizeWindow-43523" 。 当您清理分支时，它还有助于使事情变得更容易，因为您可以查找相关的错误。 这就是我通常命名我的分支的方式。

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

Answer 6

请注意，如提交 e703d7或提交 b6c2a0d （2014 年 3 月）中所示，现在是 Git 2.0 的一部分，您会发现另一个命名约定（您可以将其应用于分支）。

“当你需要使用空格时，使用破折号”是一种奇怪的说法，你不能使用空格。
因为命令行描述使用虚线多字更为常见，所以您甚至不想在这些地方使用空格。

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

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

Answer 7

按照 farktronix 的建议，我们一直在 mercurial 中使用 Jira 票号，我打算继续将它们用于 git 分支。 但我认为票号本身可能足够独特。 虽然正如 farktronix 指出的那样，在分支名称中包含一个描述性词可能会有所帮助，但如果您在分支之间切换的频率足够高，您可能希望减少输入。 那么如果你需要知道分支名称，如果你不知道的话，在Jira中寻找ticket中相关的关键字。 此外，您应该在每条评论中包含票号。

如果您的分支代表一个版本，那么常见的约定似乎是使用 xxx（例如：“1.0.0”）格式作为分支名称和 vx.xx（例如“v1.0.0”）作为标签名称（以避免冲突） . 另见： is-there-an-standard-naming-convention-for-git-tags