git - 命名 git 分支的常用做法有哪些示例？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

5年前关闭。



Improve this question




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

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

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

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

Answer 1

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

分支命名约定

在分支名称的开头使用分组标记(单词)。

定义和使用短线索标记以对您的工作流程有意义的方式区分分支。

使用斜杠分隔分支名称的各个部分。

不要使用裸数字作为前导部分。

避免为长期存在的分支使用长的描述性名称。

集团代币

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

group1/foo
group2/foo
group1/bar
group2/bar
group3/bar
group1/baz

这些组可以任意命名以匹配您的工作流程。我喜欢用短名词来形容我的。继续阅读以获得更清晰的信息。

定义明确的短 token

选择短标记，这样它们就不会给您的每个分支名称添加太多干扰。我使用这些:

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

这些 token 中的每一个都可用于告诉您每个分支属于工作流的哪个部分。

听起来您有多个分支用于不同的更改周期。我不知道您的周期是什么，但让我们假设它们是“新的”、“测试的”和“验证的”。您可以使用这些标签的缩写版本命名您的分支，始终以相同的方式拼写，以便将它们分组并提醒您处于哪个阶段。

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 然后给我一个分支列表，这些分支与我输入的 token 部分相匹配。这适用于前面的 token 以及嵌入的 token 。

$ 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 提交”中会更有帮助。默认 merge 提交消息是 Merge branch 'branch-name' .您可能会发现将 merge 消息显示为 Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted' 更有帮助。而不仅仅是 Merge branch 'fix/CR15032' .