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

What are some examples of commonly used practices for naming git branches?

提问by skiphoppy

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.

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

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?

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

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.)

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

回答by phord

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.

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

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 的模式匹配选项轻松地将它们组合在一起。

$ 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.

对我来说，斜线也更适合我的 shell 中的选项卡扩展（命令完成）。按照我的配置方式，我可以通过键入部件的第一个字符并按 TAB 键来搜索具有不同子部件的分支。Zsh 然后给我一个分支列表，这些分支与我输入的令牌部分相匹配。这适用于前面的令牌以及嵌入的令牌。

$ 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.)

（Zshell 在命令完成方面是非常可配置的，我也可以将其配置为以相同的方式处理破折号、下划线或点。但我选择不这样做。）

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

它还允许您在许多 git 命令中搜索分支，如下所示：

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.

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

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 可能会决定一个数字是 sha-1 的一部分而不是分支名称。例如，我的问题跟踪器使用十进制数字命名错误。我将我的相关分支命名为 CRnnnnn 而不仅仅是 nnnnn 以避免混淆。

$ 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.

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

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'.

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

回答by Brian Carlton

A successful Git branching modelby Vincent Driessen has good suggestions. A picture is below. If this branching model appeals to you consider the flow extension to git. Others have commented about flow

Vincent Driessen 的一个成功的 Git 分支模型有很好的建议。下面是一张图片。如果此分支模型吸引您，请考虑将流扩展到 git。其他人评论了流量

Driessen's model includes

Driessen 的模型包括

• A master branch, used only for release. Typical name master.

• A "develop" branch off of that branch. That's the one used for most main-line work. Commonly named develop.

• Multiple feature branches off of the develop branch. Name based on the name of the feature. These will be merged back into develop, not into the master or release branches.

• Release branch to hold candidate releases, with only bug fixes and no new features. Typical name rc1.1.

• 一个主分支，仅用于发布。典型名称master。

• 该分支的“开发”分支。这是用于大多数主线工作的一种。俗称develop。

• 开发分支的多个功能分支。基于特征名称的名称。这些将被合并回开发，而不是主分支或发布分支。

• 发布分支来保存候选版本，只有错误修复，没有新功能。典型名称rc1.1。

Hotfixes are short-lived branches for changes that come from master and will go into master without development branch being involved.

修补程序是来自 master 的更改的短期分支，将在不涉及开发分支的情况下进入 master。

回答by Aristotle Pagaltzis

My personal preference is to delete the branch name after I'm done with a topic branch.

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

Instead of trying to use the branch name to explain the meaning of the branch, I start the subject line of the commit message in the first commit on that branch with “Branch:” and include further explanations in the body of the message if the subject does not give me enough space.

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

The branch name in my use is purely a handle for referring to a topic branch while working on it. Once work on the topic branch has concluded, I get rid of the branch name, sometimes tagging the commit for later reference.

我使用的分支名称纯粹是用于在处理主题分支时引用该分支的句柄。一旦主题分支的工作结束，我就会去掉分支名称，有时会标记提交以供以后参考。

That makes the output of git branchmore useful as well: it only lists long-lived branches and active topic branches, not all branches ever.

这也使得输出git branch更有用：它只列出长期存在的分支和活动主题分支，而不是所有分支。

回答by MikeG

I've mixed and matched from different schemes I've seen and based on the tooling I'm using.
So my completed branch name would be:

我根据我使用的工具混合和匹配了我见过的不同方案。
所以我完成的分支名称将是：

name/feature/issue-tracker-number/short-description

名称/功能/问题跟踪器编号/简短描述

which would translate to:

这将转化为：

mike/blogs/RSSI-12/logo-fix

迈克/博客/RSSI-12/logo-fix

The parts are separated by forward slashes because those get interpreted as folders in SourceTree for easy organization. We use Jira for our issue tracking so including the number makes it easier to look up in the system. Including that number also makes it searchable when trying to find that issue inside Github when trying to submit a pull request.

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

回答by farktronix

Why does it take three branches/merges for every task? Can you explain more about that?

为什么每个任务都需要三个分支/合并？你能解释更多吗？

If you use a bug tracking system you can use the bug number as part of the branch name. This will keep the branch names unique, and you can prefix them with a short and descriptive word or two to keep them human readable, like "ResizeWindow-43523". It also helps make things easier when you go to clean up branches, since you can look up the associated bug. This is how I usually name my branches.

如果您使用错误跟踪系统，您可以使用错误编号作为分支名称的一部分。这将保持分支名称的唯一性，您可以用一两个简短的描述性词作为前缀，以保持它们的可读性，例如"ResizeWindow-43523". 当您清理分支时，它还有助于使事情变得更容易，因为您可以查找相关的错误。这就是我通常命名我的分支的方式。

Since these branches are eventually getting merged back into master, you should be safe deleting them after you merge. Unless you're merging with --squash, the entire history of the branch will still exist should you ever need it.

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

回答by VonC

Note, as illustrated in the commit e703d7or commit b6c2a0d(March 2014), now part of Git 2.0, you will find another naming convention (that you can apply to branches).

请注意，如提交 e703d7或提交 b6c2a0d（2014 年 3 月）中所示，现在是 Git 2.0 的一部分，您会发现另一个命名约定（您可以将其应用于分支）。

"When you need to use space, use dash" is a strange way to say that you must not use a space.
Because it is more common for the command line descriptions to use dashed-multi-words, you do not even want to use spaces in these places.

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

A branch name cannot have space (see "Which characters are illegal within a branch name?" and git check-ref-formatman page).

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

So for every branch name that would be represented by a multi-word expression, using a '-' (dash) as a separator is a good idea.

因此，对于由多词表达式表示的每个分支名称，使用“ -”（破折号）作为分隔符是一个好主意。

回答by Gary S. Weaver

Following up on farktronix's suggestion, we have been using Jira ticket numbers for similar in mercurial, and I'm planning to continue using them for git branches. But I think the ticket number itself is probably unique enough. While it might be helpful to have a descriptive word in the branch name as farktronix noted, if you are switching between branches often enough, you probably want less to type. Then if you need to know the branch name, look in Jira for the associated keywords in the ticket if you don't know it. In addition, you should include the ticket number in each comment.

按照 farktronix 的建议，我们一直在 mercurial 中使用 Jira 票号，我打算继续将它们用于 git 分支。但我认为票号本身可能足够独特。虽然正如 farktronix 指出的那样，在分支名称中包含一个描述性词可能会有所帮助，但如果您在分支之间切换的频率足够高，您可能希望减少输入。那么如果你需要知道分支名称，如果你不知道的话，在Jira中寻找ticket中相关的关键字。此外，您应该在每条评论中包含票号。

If your branch represents a version, it appears that the common convention is to use x.x.x (example: "1.0.0") format for branch names and vx.x.x (example "v1.0.0") for tag names (to avoid conflict). See also: is-there-an-standard-naming-convention-for-git-tags

如果您的分支代表一个版本，那么常见的约定似乎是使用 xxx（例如：“1.0.0”）格式作为分支名称和 vx.xx（例如“v1.0.0”）作为标签名称（以避免冲突） . 另请参阅：is-there-an-standard-naming-convention-for-git-tags