git分支命名最佳实践
我已经使用了一个本地的git仓库，与我的团队的CVS仓库进行数月的交互。 我做了一个几乎神经质的分支，其中大部分已经合并到我的箱子里了。 但命名开始成为一个问题。 如果我有一个简单的标签命名的任务，但是我分三个阶段完成，每个阶段都包含自己的分支和合并情况，那么我可以每次都重复分支名称，但这会使历史有点混乱。 如果我在名称上更加具体，每个阶段都有单独的描述，那么分支名称就会变得漫长而笨拙。
我确实在这里学习了一些旧线程，我可以用这个名字来命名分支，比如topic / task，或者类似的东西。 我可能会开始这样做，看看是否有助于保持组织更好。
命名git分支的一些最佳实践是什么？
编辑：没有人提出任何命名约定。 我完成删除分支。 由于pipe理层不断调整优先顺序，我恰好碰巧有几个。 :)作为一个为什么我可能需要在一个任务上有多个分支的示例，假设我需要将任务中的第一个离散里程碑提交给组的CVS存储库。 在那个时候，由于我与CVS的交互不完善，我会执行这个提交，然后杀死那个分支。 （如果我试图在这一点上继续使用同一个分支，我已经看到了太多与CVS交互的奇怪现象。）
这里有一些我使用的分支命名约定和原因
分支命名约定
- 在分支名称的开头使用分组标记（单词）。
- 定义并使用简短的标记，以对工作stream程有意义的方式区分分支。
- 使用斜杠来分隔部分的分支名称。
- 不要使用裸数字作为主要部分。
- 避免长期分支的长描述性名称。
组令牌
在分支名称前使用“分组”标记。
group1/foo group2/foo group1/bar group2/bar group3/bar group1/baz
无论您喜欢与您的工作stream程相匹配，这些组都可以被命名。 我喜欢用我的短名词。 阅读更清晰。
短明确的标记
select简短的令牌，这样它们不会为每个分支名称添加太多的噪音。 我使用这些：
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
每个令牌都可以用来告诉你每个分支所属的工作stream程的哪个部分。
这听起来像你有不同的变化周期的多个分支。 我不知道你的周期是什么，但我们假设他们是“新”，“testing”和“validation”。 你可以用这些标签的缩写版本给你的分支命名，总是拼写相同的方式，将它们分组，并提醒你你在哪个阶段。
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中的标签扩展（命令完成）。 我已经configuration的方式，我可以通过键入部件的第一个字符，然后按TAB键来search具有不同子部分的分支。 Zsh然后给我一个分支的列表，它与我input的令牌的部分匹配。 这适用于以前的令牌以及embedded的。
$ git checkout new<TAB> Menu: new/frabnotz new/foo new/bar $ git checkout foo<TAB> Menu: new/foo test/foo ver/foo
（关于命令完成，Zshell是非常可configuration的，我也可以configuration它来处理破折号，下划线或点，但我select不这样做）。
它也可以让你在许多git命令中search分支，如下所示：
git branch --list "feature/*" git log --graph --oneline --decorate --branches="feature/*" gitk --branches="feature/*"
警告：正如Slipp在评论中指出的那样，斜线可能会导致问题。 因为分支是作为path实现的，所以不能有一个名为“foo”的分支和另一个名为“foo / bar”的分支。 这可能会让新用户感到困惑。
不要使用裸号码
不要使用裸号码（或hex数字）作为分支命名scheme的一部分。 在引用名称的tab扩展中，git可以决定一个数字是sha-1而不是分支名称的一部分。 例如，我的问题跟踪器用十进制数字命名错误。 为了避免混淆，我将相关分支命名为CRnnnnn，而不仅仅是nnnnnn。
$ git checkout CR15032<TAB> Menu: fix/CR15032 test/CR15032
如果我试图扩展15032，git将不确定是否要searchSHA-1或分支名称，我的select会有所限制。
避免使用长的描述性名称
当您查看分行列表时，长分行名称可能非常有用。 但是，当查看装饰的单行日志时，它可能会阻碍，因为分支名称可能会占用大部分单行，并缩短了日志的可见部分。
另一方面，如果你不习惯性地重写它们，长分支名字可以在“合并提交”中更有帮助。 默认合并提交消息是Merge branch 'branch-name' 。 您可能会发现合并消息显示为Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted'而不是Merge branch 'fix/CR15032' 。
Vincent Driessen 成功的Git分支模型有很好的build议。 下面是一张照片。 如果这个分支模型吸引你考虑stream扩展到git 。 其他人则评论stream量
Driessen的模型包括
-
主分支，仅用于发布。 典型的名字
master。 -
该分支的“发展”分支。 这是大多数主线工作所使用的。 典型的名字
devel。 -
开发分支的多个function分支。 名称基于function的名称。 这些将被合并回开发，而不是进入主或分支分支。
-
发布分支来保存候选版本，只有错误修复和没有新function。 典型名称
rc1.1。
修补程序是来自主服务器的更改的短期分支，如果不涉及开发分支，它将进入主服务器。
我个人偏好是在完成主题分支后删除分支名称。
我没有试图用分支名称来解释分支的含义，而是使用“Branch：”在该分支的第一个提交中启动提交消息的主题行，并在消息正文中包含进一步的解释没有给我足够的空间。
在我使用的分支名称纯粹是一个处理它的引用主题分支的句柄。 一旦主题分支的工作已经结束，我摆脱了分支名称，有时标记提交供以后参考。
这使得git branch的输出也更加有用：它只列出长期分支和活动主题分支，而不是所有分支。
我从我看到的不同计划中混合和匹配，并基于我正在使用的工具。 所以我完成的分支名称是：
名称/特征/问题跟踪数/短说明
这将转化为：
麦克/博客/ RSSI-12 /标志修复
这些部分由正斜杠分隔，因为这些部分被解释为SourceTree中的文件夹，以便于组织。 我们使用Jira来进行问题跟踪，因此包括该号码可以更容易在系统中查找。 在尝试提交请求时，在Github中尝试查找该问题时，包含该数字也会使其可search。
为什么每个任务需要三个分支/合并？ 你能解释一下吗？
如果您使用错误跟踪系统，则可以使用错误编号作为分支名称的一部分。 这将保持分支名称的独特性，并且可以在它们"ResizeWindow-43523"添加一个简短的描述性字词，以保持它们的可读性，如"ResizeWindow-43523" 。 当你去清理分支时，它也可以帮助你更容易，因为你可以查找相关的错误。 这是我通常如何命名我的分支。
由于这些分支最终会被合并回主，所以在合并之后应该安全地删除它们。 除非你和--squash合并，否则如果你需要的--squash ，分支的整个历史将会一直存在。
请注意，如提交e703d7或提交b6c2a0d （2014年3月）（现在是Git 2.0的一部分）中所示，您会发现另一个命名约定（可应用于分支机构）。
“当你需要使用空间，使用短划线”是一个奇怪的方式，说你不能使用空间。
因为命令行描述使用虚线多词更常见，所以甚至不希望在这些地方使用空格。
分支名称不能有空格（请参阅“ 哪个字符在分支名称内是不合法的？ ”和git check-ref-format手册页 ）。
因此，对于将由多词expression式表示的每个分支名称，使用“ - ”（破折号）作为分隔符是一个好主意。
跟随farktronix的build议，我们一直在使用Jira门票号码类似于mercurial，我打算继续使用他们的git分支。 但是我觉得票号本身可能是独一无二的。 如farktronix指出的那样，在分支名称中使用描述性字词可能会有所帮助，但如果您经常在分支之间进行切换，则可能需要input较less的字符。 那么如果您需要知道分行名称，请查看Jira中的相关关键字（如果您不知道）。 另外，您应该在每条评论中包含票号。
如果你的分支代表一个版本，看起来公共约定是使用分支名称的xxx（例如“1.0.0”）格式和标签名称的vx.xx（例如“v1.0.0”）（为了避免冲突） 。 另请参阅：这是一个标准命名约定为git标签
