git - 命名 git 分支的常用做法有哪些示例?

标签 git naming-conventions branch

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗?更新问题,以便可以通过 editing this post 用事实和引文回答问题.

5年前关闭。



Improve this question




几个月来,我一直在使用本地 git 存储库与我组的 CVS 存储库交互。我已经制作了几乎神经质的分支数量,幸运的是,其中大部分已经 merge 回了我的树干。但命名开始成为一个问题。如果我有一个任务很容易用简单的标签命名,但我分三个阶段完成,每个阶段都包含自己的分支和 merge 情况,那么我可以每次重复分支名称,但这会使历史变得有点困惑。如果我在名称中得到更具体的内容,对每个阶段都有单独的描述,那么分支名称就会开始变得冗长而笨拙。

我确实在这里学习了查看旧线程,我可以开始在名称中使用/命名分支,即主题/任务或类似的东西。我可能会开始这样做,看看它是否有助于让事情更有条理。

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

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

最佳答案

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

分支命名约定

  • 在分支名称的开头使用分组标记(单词)。
  • 定义和使用短线索标记以对您的工作流程有意义的方式区分分支。
  • 使用斜杠分隔分支名称的各个部分。
  • 不要使用裸数字作为前导部分。
  • 避免为长期存在的分支使用长的描述性名称。

  • 集团代币

    在分支名称前使用“分组”标记。
    group1/foo
    group2/foo
    group1/bar
    group2/bar
    group3/bar
    group1/baz
    

    这些组可以任意命名以匹配您的工作流程。我喜欢用短名词来形容我的。继续阅读以获得更清晰的信息。

    定义明确的短 token

    选择短标记,这样它们就不会给您的每个分支名称添加太多干扰。我使用这些:
    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
    

    这些 token 中的每一个都可用于告诉您每个分支属于工作流的哪个部分。

    听起来您有多个分支用于不同的更改周期。我不知道您的周期是什么,但让我们假设它们是“新的”、“测试的”和“验证的”。您可以使用这些标签的缩写版本命名您的分支,始终以相同的方式拼写,以便将它们分组并提醒您处于哪个阶段。
    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 然后给我一个分支列表,这些分支与我输入的 token 部分相匹配。这适用于前面的 token 以及嵌入的 token 。
    $ 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 的一部分而不是分支名称。例如,我的问题跟踪器使用十进制数字命名错误。我将我的相关分支命名为 CRnnnnn 而不仅仅是 nnnnn 以避免混淆。
    $ git checkout CR15032<TAB>
    Menu:   fix/CR15032    test/CR15032
    

    如果我尝试仅扩展 15032,git 将不确定我是要搜索 SHA-1 名称还是分支名称,而且我的选择会受到一定限制。

    避免使用长的描述性名称

    当您查看分支列表时,长分支名称非常有用。但是在查看装饰的单行日志时,它可能会造成妨碍,因为分支名称会占用单行的大部分内容并缩写日志的可见部分。

    另一方面,如果您不习惯性地手动重写它们,长分支名称在“merge 提交”中会更有帮助。默认 merge 提交消息是 Merge branch 'branch-name' .您可能会发现将 merge 消息显示为 Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted' 更有帮助。而不仅仅是 Merge branch 'fix/CR15032' .

    关于git - 命名 git 分支的常用做法有哪些示例?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/273695/

    相关文章:

    c++ - 使用 cmake 和 QT 组织多个项目

    python - 使用 GitPython 查找分支上的第一个提交

    mysql - 用于依赖项的术语

    namespaces - 如果我有一个多词名称,thrift 命名空间的命名约定是什么?

    version-control - Mercurial:如果标签具有相同的名称,如何切换到命名分支?

    git - 执行 git commit 后删除文件,验证它不在 master 中

    java - 如何使用 Libgdx 和 Intellij Idea 在多台计算机上进行开发

    java - Java 中实用程序类的命名约定

    git - 如何让git显示所有本地分支的最近n次提交

    mercurial - Capistrano、Mercurial 和分支机构