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

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

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

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

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

1> phord..：

---

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

分支命名约定

在分支名称的开头使用分组令牌(单词).

定义和使用短引导令牌,以对您的工作流程有意义的方式区分分支.

使用斜杠分隔部分名称.

不要使用裸号作为主要部分.

避免长寿命分支的长描述性名称.

集团代币

在分支名称前面使用"分组"标记.

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
Menu:  new/frabnotz   new/foo   new/bar


$ git checkout foo
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
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'.

---

使用像`bug/20574/frabnotz-finder`和`bug/20424`这样的混合形式的一个缺点是,一旦你没有子令牌开始,你就不能再添加一个,反之亦然._E.G.:如果你创建一个`bug/20424`分支,你不能在以后创建一个`bug/20424/additional-fixing`分支(除非你删除`bug/20424`分支).同样,如果`bug/20574/frabnotz-finder`已经是一个分支,你就不能创建一个`bug/20574`分支.我倾向于在这种情况下使用非子令牌分隔符(例如` bug/20574_frabnotz-finder`),或选择子令牌的默认名称(例如`bug/20424/main`).

---

我将开始一个从不在git branch命名中使用斜杠的活动.这样做的原因是,例如,如果在CI上,您希望在打包代码时引用分支名称,则需要在构建uri或PATH(例如)时引用分支的名称,也许是建立bash脚本中的uri; 由于斜线添加了url部分,你将无法构建uri.是的,它有可能取代斜线,但这需要我花很多时间来整理.

---

在某些情况下,正斜杠对git有意义吗？例如,响应`git branch -a`,并获取`remotes/origin/master`等等.当我看到git告诉我一个分支时,我不使用正斜杠,所以当我看到一个时,我知道这是一个"特殊"的参考.

---

你能用一些例子而不是foo和bar吗？

---

它还具有提示一些基于Git GUI的工具以允许折叠令牌分区(如目录列表视图)的好处.在上面的例子中,你会看到一个`feature`组和一个`bug`组,可以扩展为显示前者的`foo`,`bar`标签和`20574`,`20592`组和'20424`,后者的'21334`标签.

2> Brian Carlto..：

---

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

Driessen的模型包括

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

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

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

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

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

---

除了它没有真正解决这个问题,因为它为用户留下了一堆命名约定,特别是对于功能分支(它们可以是"除master之外的任何东西,开发,发布 - *或hotfix-*"

---

"持续交付"(第36页)一书认为,这种模式与持续整合是对立的......实质上,它并不是真正的"敏捷".

---

尽管提供了很好的信息，但该答案解决的是流程问题，而不是命名约定。我认为OP希望知道要使用的实际单词（名词与动词），定界符，大小写等。

3> Aristotle Pa..：

---

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

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

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

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

4> MikeG..：

---

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

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

这将转化为:

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

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

---

我使用相同的,除了我传递问题编号以及描述:`name/feature/issue-tracker-number-short-description`

5> farktronix..：

---

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

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

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

6> VonC..：

---

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

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

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

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

7> Gary S. Weav..：

---

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

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

---

我最近使用了一个repo,我们使用相同名称的标签为每个版本分支上限.它工作得很好,因为它没有任何歧义(标签指向大多数情况下相应分支上的最后一次提交),并且当可能存在时,Git"做正确的事情"(带警告).我更喜欢它,因为如果有人犯了一个愚蠢的错误并且进一步向一个封顶的分支提交,Git将继续选择标签,这就是意图.当系统控制一切时,模糊性可以使事情变得更简单,并且意图很明确.