有哪些常用的命名git分支实例的例子? [关闭]

2019/12/13 21:50
阅读数 143

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

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

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

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


#1楼

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

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

这将转化为:

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

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


#2楼

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

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


#3楼

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

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

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

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


#4楼

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

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

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

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


#5楼

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

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

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

展开阅读全文
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部