现在,我已经使用本地git存储库与我的组的CVS存储库进行了几个月的交互 . 我已经制作了一个几乎神经质的分支,其中大多数幸运地合并回我的 Baggage 箱 . 但命名开始成为一个问题 . 如果我有一个很容易用简单标签命名的任务,但是我在三个阶段完成它,每个阶段都包含它们自己的分支和合并情况,那么我每次都可以重复分支名称,但这会使历史有点混乱 . 如果我在名称中有更具体的说明,并且每个阶段都有单独的描述,那么分支名称开始变得冗长且难以处理 .
我确实学习了查看旧线程,我可以开始用名称中的/来命名分支,即主题/任务,或类似的东西 . 我可能会开始这样做,看看它是否有助于保持更好的组织 .
命名git分支有哪些最佳实践?
编辑:没有人实际建议任何命名约定 . 我完成后会删除分支 . 由于管理层不断调整我的优先事项,我恰巧有几个人 . :)作为为什么我可能需要在任务上需要多个分支的示例,假设我需要将任务中的第一个离散里程碑提交到组的CVS存储库 . 那时,由于我与CVS的不完美交互,我会执行该提交然后杀死该分支 . (如果我在此时尝试继续使用相同的分支,我看到太多奇怪的事情与CVS交互 . )
7 回答
以下是我使用的一些分支命名约定及其原因
Branch naming conventions
在分支名称的开头使用分组令牌(单词) .
定义并使用短引导令牌以对工作流有意义的方式区分分支 .
使用斜杠分隔部分名称 .
不要使用裸号作为前导部分 .
避免使用长期分支的长描述性名称 .
Group tokens
在分支名称前面使用“分组”标记 .
这些组可以根据您的工作流程命名 . 我喜欢用我的短名词 . 继续阅读以获得更清晰 .
Short well-defined tokens
选择短标记,这样它们就不会为每个分支名称添加太多噪音 . 我用这些:
这些令牌中的每一个都可用于告诉您每个分支属于哪个工作流程部分 .
听起来你有多个分支用于不同的变化周期 . 我不知道你的周期是什么,但让我们假设他们是'新','测试'和'验证' . 您可以使用这些标签的缩写版本命名您的分支,总是以相同的方式拼写,以便对它们进行分组并提醒您所处的阶段 .
您可以快速判断哪些分支到达了每个不同的阶段,您可以使用Git的模式匹配选项轻松地将它们组合在一起 .
Use slashes to separate parts
您可以在分支名称中使用大多数您喜欢的分隔符,但我发现斜杠是最灵活的 . 您可能更喜欢使用破折号或圆点 . 但是斜杠允许您在推送或从远程读取数据时进行一些分支重命名 .
对我来说,斜杠也更适合我的shell中的选项卡扩展(命令完成) . 我配置它的方式我可以通过键入部件的第一个字符并按TAB键来搜索具有不同子部件的分支 . Zsh然后给我一个分支列表,它与我输入的令牌部分相匹配 . 这适用于前面的令牌以及嵌入的令牌 .
(Zshell对命令完成非常可配置,我也可以配置它以同样的方式处理破折号,下划线或点 . 但我选择不这样做 . )
它还允许您在许多git命令中搜索分支,如下所示:
警告:正如Slipp在评论中指出的那样,斜线可能会导致问题 . 因为分支是作为路径实现的,所以不能有名为“foo”的分支和名为“foo / bar”的另一个分支 . 这可能会让新用户感到困惑 .
Do not use bare numbers
不要使用裸号(或十六进制数)作为分支命名方案的一部分 . 在引用名称的制表符扩展内,git可以决定数字是sha-1的一部分而不是分支名称 . 例如,我的问题跟踪器使用十进制数字命名错误 . 我将我的相关分支命名为CRnnnn而不仅仅是nnnnn以避免混淆 .
如果我试图扩展15032,git将不确定我是否想要搜索SHA-1或分支名称,我的选择会有所限制 .
Avoid long descriptive names
当您查看分支列表时,长分支名称可能非常有用 . 但是,当查看装饰的单行日志时,它可能会妨碍,因为分支名称会占用大部分单行并缩短日志的可见部分 .
另一方面,如果你不习惯性地手工重写它们,那么长分支名称在_745613中会更有帮助 . 默认的合并提交消息是
Merge branch 'branch-name'
. 您可能会发现它更有帮助合并消息显示为Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted'
而不是Merge branch 'fix/CR15032'
.A successful Git branching model由Vincent Driessen提出了很好的建议 . 一张图片如下 . 如果这个分支模型吸引你考虑flow extension to git . 其他人有commented about flow
Driessen的模型包括
主分支,仅用于发布 . 典型名称
master
."develop"从该分支分支出来 . 这是用于大多数主线工作的那个 . 通常命名为
develop
.开发分支的多个功能分支 . 名称基于功能的名称 . 这些将合并回开发,而不是合并到主分支或发布分支 .
发布分支以保留候选版本,仅修复错误而没有新功能 . 典型名称
rc1.1
.修补程序是来自主服务器的更改的短期分支,并且将在不涉及开发分支的情况下进入主服务器 .
我个人的偏好是在完成主题分支后删除分支名称 .
我没有尝试使用分支名称来解释分支的含义,而是使用“Branch:”在该分支的第一次提交中启动提交消息的主题行,如果主题包含在消息正文中的进一步解释不给我足够的空间 .
我使用的分支名称纯粹是在处理主题分支时引用主题分支的句柄 . 一旦关于主题分支的工作结束,我就会删除分支名称,有时会标记提交以供以后参考 .
这使得
git branch
的输出也更有用:它只列出了长寿分支和活动主题分支,而不是所有分支 .我已经看到了不同的方案并基于我正在使用的工具进行混合和匹配 . 所以我完成的分支名称将是:
这将转化为:
这些部分由正斜杠分隔,因为它们在SourceTree中被解释为文件夹以便于组织 . 我们使用Jira进行问题跟踪,因此包含该数字可以更容易地在系统中查找 . 当尝试在提交拉取请求时尝试在Github中找到该问题时,包括该数字也使其可搜索 .
为什么每个任务需要三个分支/合并?你能解释一下这个吗?
如果您使用错误跟踪系统,则可以将错误编号用作分支名称的一部分 . 这将使分支名称保持唯一,并且您可以在它们前面添加一个简短的描述性字词,以使它们具有人类可读性,例如
"ResizeWindow-43523"
. 当你去清理分支时,它还有助于简化操作,因为你可以查找相关的bug . 这就是我通常用我的分支命名的方式 .由于这些分支最终会合并回master,因此在合并后应该安全地删除它们 . 除非你与
--squash
合并,否则如果你需要它,分支的整个历史仍然存在 .请注意,如commit e703d7或commit b6c2a0d(2014年3月)所示,现在是Git 2.0的一部分,您将找到另一个命名约定(可以应用于分支) .
分支名称不能包含空格(请参阅“Which characters are illegal within a branch name?”和git check-ref-format man page) .
因此,对于将由多字表达式表示的每个分支名称,使用'
-
'(破折号)作为分隔符是个好主意 .继farktronix的建议之后,我们一直在使用Jira票号来表示类似的情况,并且我打算继续将它们用于git分支 . 但我认为票号本身可能足够独特 . 虽然如farktronix所指出的那样在分支名称中包含描述性单词可能会有所帮助,但如果您经常在分支之间进行切换,则可能需要更少的输入 . 然后,如果您需要知道分支名称,请在Jira中查找故障单中的关联关键字(如果您不知道它) . 此外,您应在每条评论中包含票号 .
如果您的分支代表一个版本,则通常的惯例似乎是对分支名称使用x.x.x(示例:"1.0.0")格式,对标记名称使用vx.x.x(示例"v1.0.0")(以避免冲突) . 另见:is-there-an-standard-naming-convention-for-git-tags