有哪些常用的命名git分支实例的例子？

Question

现在,我已经使用本地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的一部分而不是分支名称.例如,我的问题跟踪器使用十进制数字命名错误.我将我的相关分支命名为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'.

Answer 2

Vincent Driessen 成功的Git分支模型有很好的建议.一张图片如下.如果这个分支模型吸引你考虑git的流扩展.其他人评论了流量

Driessen的模型包括

• 主分支,仅用于发布.典型名称master.

• 该分支的"开发"分支.这是用于大多数主线工作的那个.通俗命名develop.

• 开发分支的多个功能分支.名称基于功能的名称.这些将合并回开发,而不是合并到主分支或发布分支.

• 发布分支以保留候选版本,仅修复错误并且没有新功能.典型名称rc1.1.

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

Answer 3

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

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

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

这使输出git branch更有用:它只列出长寿分支和活动主题分支,而不是所有分支.

Answer 4

我已经看到了基于我正在使用的工具的不同方案的混合和匹配.所以我完成的分支名称将是:

名称/特征/问题跟踪数/短说明

这将转化为:

麦克/博客/ RSSI-12 /标志修复

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

Answer 5

为什么每个任务需要三个分支/合并？你能解释一下这个吗？

如果您使用错误跟踪系统,则可以将错误编号用作分支名称的一部分.这将使分支名称保持唯一,并且您可以在它们前面添加一个简短的描述性词语,以使它们具有人类可读性,例如"ResizeWindow-43523".当你去清理分支时,它还有助于简化操作,因为你可以查找相关的bug.这就是我通常用我的分支命名的方式.

由于这些分支最终会合并回master,因此在合并后应该安全地删除它们.除非你合并,否则如果--squash你需要它,分支的整个历史仍然存在.

Answer 6

请注意,如提交e703d7或提交b6c2a0d (2014年3月)中所示,现在是Git 2.0的一部分,您将找到另一个命名约定(可以应用于分支).

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

分支名称不能有空格(请参阅" 分支名称中哪些字符是非法的？ "和git check-ref-format手册页).

因此,对于将由多字表达式表示的每个分支名称,使用' -'(破折号)作为分隔符是个好主意.

Answer 7

继farktronix的建议之后,我们一直在使用Jira票号来表示类似的情况,我打算继续将它们用于git分支.但我认为票号本身可能足够独特.虽然如farktronix所指出的那样在分支名称中包含描述性单词可能会有所帮助,但如果您经常在分支之间进行切换,则可能需要更少的输入.然后,如果您需要知道分支名称,请在Jira中查找故障单中的关联关键字(如果您不知道它).此外,您应在每条评论中包含票号.

如果您的分支代表一个版本,则通常的约定是对分支名称使用xxx(例如:"1.0.0")格式,对标记名称使用vx.xx(例如"v1.0.0")(以避免冲突) .另请参阅:is-there-an-standard-naming-convention-for-git-tags