git分支命名最佳实践 [英] git branch naming best practices

问题描述

现在，我已经使用了一个本地git存储库，与我的组的CVS存储库进行数月的交互。我做了一个几乎神经质的分支，其中大部分已经合并回我的箱子里了。但命名开始成为一个问题。如果我有一个简单的标签命名任务，但是我分三个阶段完成，每个阶段都包含他们自己的分支和合并情况，那么每次都可以重复分支名称，但这会使历史有点混乱。如果我在名称中更具体，每个阶段都有单独的描述，那么分支名称会变得漫长而笨拙。

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

命名git分支的一些最佳做法是什么？

编辑：
实际上没有人提出任何命名约定。
当我完成它们时，我会删除分支。由于管理层不断调整我的优先事项，我恰好有几处。 :)
作为一个为什么我可能需要在一个任务上有多个分支的例子，假设我需要将任务中的第一个离散里程碑提交给组的CVS存储库。此时，由于我与CVS的交互不完善，我会执行该提交并杀死该分支。 （如果我试图继续使用同一个分支，我已经看到了太多与CVS交互的奇怪现象。）

解决方案

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

$ b 分支命名约定

1. 在分支名称的开始处使用分组标记（单词）。


2. 定义并使用短主标记以某种方式区分分支对您的工作流程有意义。


3. 使用斜杠分隔部分分支名称。


4. 不要将裸数字用作主要部分。 >
   
5. 为长期分支机构避免使用长描述性名称。

群组令牌

在分支名称前使用分组标记。

  group1 / foo 
 group2 / foo 
 group1 / bar 
 group2 / bar 
 group3 / bar 
 group1 / baz 
  

无论你喜欢什么，匹配你的工作流程我喜欢用我的短名词。
$ b 短定义标记

选择短令牌，所以它们不会为每个分支名称添加太多噪音。我使用这些：

  wip工作正在进行中;我知道的东西不会很快完成
 feat功能我正在添加或扩展
 bug错误修复或实验
垃圾创建Throwaway分支来实验
  

这些标记都可以用来告诉您每个分支属于哪个工作流程部分。

听起来你有多个分支用于不同的更改周期。我不知道你的周期是什么，但我们假设他们是'新'，'测试'和'验证'。你可以给分支命名你的分支，这些标签的缩写版本总是以相同的方式拼写，将它们分组，并提醒你你在哪个阶段。

 新/ frabnotz 
新/ foo 
新/ bar 
测试/ foo 
测试/ frabnotz 
 ver / foo 
  

您可以快速确定哪些分支已经到达每个不同阶段，并且可以使用Git的模式匹配选项轻松地将它们组合在一起。 / p>

  $ git branch --listtest / *
 test / foo 
 test / frabnotz 
 
 $ git branch --list* / foo
 new / foo 
 test / foo 
 ver / foo 
 
 $ gitk  - branches =* / foo
  

使用斜杠分隔零件 p>

您可以在分支名称中使用大多数您喜欢的分隔符，但我认为斜杠是最灵活的。您可能更喜欢使用短划线或点。但斜线可以让您在推送或从远程获取/从远程进行分支重命名。

  $ 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< TAB> 
菜单：new / frabnotz new / foo new / bar 
 
 
 $ git checkout foo< TAB> 
 Menu：new / foo test / foo ver / foo 
  

（Zshell可配置命令完成，我也可以配置它来处理破折号，下划线或点，但我选择不）。 git命令，如下所示：

  git branch --listfeature / *
 git log --graph  - -oneline --decorate --branches =feature / *
 gitk --branches =feature / *
  

警告：正如Slipp在评论中指出的那样，斜杠可能会导致问题。因为分支被实现为路径，所以不能有名为foo的分支和名为foo / bar的另一分支。这可能会让新用户感到困惑。

不要使用裸数字

不要使用裸号码（或十六进制数字）作为分支命名方案的一部分。在引用名称的tab扩展中，git可能会决定一个数字是sha-1的一部分，而不是分支名称。例如，我的问题跟踪器用十进制数字命名错误。为了避免混淆，我将相关分支命名为CRnnnnn，而不仅仅是nnnnn。

  $ git checkout CR15032< TAB> 
 Menu：fix / CR15032 test / CR15032 
  

如果我试图扩展15032，git将不确定我是否想要搜索SHA-1或分支名称，而我的选择会有所限制。

避免长描述性名称

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

另一方面，如果您不习惯性地用手重写它们，长分支名称在合并提交中可能会更有帮助。默认合并提交消息是合并分支'分支名称'。您可能会发现将合并消息显示为合并分支的修复/ CR15032 /未格式化磁盘时崩溃时而不是<$ c $更有帮助c>合并分支'fix / CR15032'。

I've been using a local git repository interacting with my group's CVS repository for several months, now. I've made an almost neurotic number of branches, most of which have thankfully merged back into my trunk. But naming is starting to become an issue. If I have a task easily named with a simple label, but I accomplish it in three stages which each include their own branch and merge situation, then I can repeat the branch name each time, but that makes the history a little confusing. If I get more specific in the names, with a separate description for each stage, then the branch names start to get long and unwieldy.

I did learn looking through old threads here that I could start naming branches with a / in the name, i.e., topic/task, or something like that. I may start doing that and seeing if it helps keep things better organized.

What are some best practices for naming git branches?

Edit: Nobody has actually suggested any naming conventions. I do delete branches when I'm done with them. I just happen to have several around due to management constantly adjusting my priorities. :) As an example of why I might need more than one branch on a task, suppose I need to commit the first discrete milestone in the task to the group's CVS repository. At that point, due to my imperfect interaction with CVS, I would perform that commit and then kill that branch. (I've seen too much weirdness interacting with CVS if I try to continue to use the same branch at that point.)

解决方案

Here are some branch naming conventions that I use and the reasons for them

Branch naming conventions

1. Use grouping tokens (words) at the beginning of your branch names.
2. Define and use short lead tokens to differentiate branches in a way that is meaningful to your workflow.
3. Use slashes to separate parts of your branch names.
4. Do not use bare numbers as leading parts.
5. Avoid long descriptive names for long-lived branches.

Group tokens

Use "grouping" tokens in front of your branch names.

group1/foo
group2/foo
group1/bar
group2/bar
group3/bar
group1/baz

The groups can be named whatever you like to match your workflow. I like to use short nouns for mine. Read on for more clarity.

Short well-defined tokens

Choose short tokens so they do not add too much noise to every one of your branch names. I use these:

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

Each of these tokens can be used to tell you to which part of your workflow each branch belongs.

It sounds like you have multiple branches for different cycles of a change. I do not know what your cycles are, but let's assume they are 'new', 'testing' and 'verified'. You can name your branches with abbreviated versions of these tags, always spelled the same way, to both group them and to remind you which stage you're in.

new/frabnotz
new/foo
new/bar
test/foo
test/frabnotz
ver/foo

You can quickly tell which branches have reached each different stage, and you can group them together easily using Git's pattern matching options.

$ git branch --list "test/*"
test/foo
test/frabnotz

$ git branch --list "*/foo"
new/foo
test/foo
ver/foo

$ gitk --branches="*/foo"

Use slashes to separate parts

You may use most any delimiter you like in branch names, but I find slashes to be the most flexible. You might prefer to use dashes or dots. But slashes let you do some branch renaming when pushing or fetching to/from a remote.

$ git push origin 'refs/heads/feature/*:refs/heads/phord/feat/*'
$ git push origin 'refs/heads/bug/*:refs/heads/review/bugfix/*'

For me, slashes also work better for tab expansion (command completion) in my shell. The way I have it configured I can search for branches with different sub-parts by typing the first characters of the part and pressing the TAB key. Zsh then gives me a list of branches which match the part of the token I have typed. This works for preceding tokens as well as embedded ones.

$ git checkout new<TAB>
Menu:  new/frabnotz   new/foo   new/bar


$ git checkout foo<TAB>
Menu:  new/foo   test/foo   ver/foo

(Zshell is very configurable about command completion and I could also configure it to handle dashes, underscores or dots the same way. But I choose not to.)

It also lets you search for branches in many git commands, like this:

git branch --list "feature/*"
git log --graph --oneline --decorate --branches="feature/*" 
gitk --branches="feature/*" 

Caveat: As Slipp points out in the comments, slashes can cause problems. Because branches are implemented as paths, you cannot have a branch named "foo" and another branch named "foo/bar". This can be confusing for new users.

Do not use bare numbers

Do not use use bare numbers (or hex numbers) as part of your branch naming scheme. Inside tab-expansion of a reference name, git may decide that a number is part of a sha-1 instead of a branch name. For example, my issue tracker names bugs with decimal numbers. I name my related branches CRnnnnn rather than just nnnnn to avoid confusion.

$ git checkout CR15032<TAB>
Menu:   fix/CR15032    test/CR15032

If I tried to expand just 15032, git would be unsure whether I wanted to search SHA-1's or branch names, and my choices would be somewhat limited.

Avoid long descriptive names

Long branch names can be very helpful when you are looking at a list of branches. But it can get in the way when looking at decorated one-line logs as the branch names can eat up most of the single line and abbreviate the visible part of the log.

On the other hand long branch names can be more helpful in "merge commits" if you do not habitually rewrite them by hand. The default merge commit message is Merge branch 'branch-name'. You may find it more helpful to have merge messages show up as Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted' instead of just Merge branch 'fix/CR15032'.

这篇关于git分支命名最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！