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
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.
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.
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.
(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:
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.
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'.
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.
Hotfixes are short-lived branches for changes that come from master and will go into master without development branch being involved.
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.
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.
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 branch more useful as well: it only lists long-lived branches and active topic branches, not all branches ever.
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.
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.
Note, as illustrated in the commit e703d7 or commit b6c2a0d (March 2014), now part of Git 2.0, you will find another naming convention (that you can apply to branches).
"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.
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.
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
发布评论
评论（7）
以下是我使用的一些分支命名约定及其原因
分支命名约定
分组标记
在分支名称前面使用“分组”标记。
这些组可以命名为任何您喜欢的名称，以符合您的工作流程。 我喜欢用短名词来表达我的意思。 请继续阅读以获得更多清晰信息。
定义明确的短标记
选择短标记，这样它们就不会为您的每个分支名称添加太多噪音。 我使用这些：
每个标记都可以用来告诉您每个分支属于工作流程的哪个部分。
听起来您有多个分支用于不同的变更周期。 我不知道你的周期是什么，但我们假设它们是“新的”、“测试的”和“已验证的”。 您可以使用这些标签的缩写版本来命名您的分支，并且始终以相同的方式拼写，以便将它们分组并提醒您处于哪个阶段。
您可以快速判断哪些分支已达到每个不同的阶段，并且可以将它们分组使用 Git 的模式匹配选项轻松组合在一起。
使用斜杠分隔各个部分
您可以在分支名称中使用您喜欢的大多数分隔符，但我发现斜杠是最灵活的。 您可能更喜欢使用破折号或点。 但是斜杠可以让您在向远程推送或获取远程时进行一些分支重命名。
对我来说，斜杠对于 shell 中的制表符扩展（命令完成）也更有效。 按照我配置的方式，我可以通过键入部分的第一个字符并按 TAB 键来搜索具有不同子部分的分支。 然后 Zsh 给我一个与我输入的令牌部分相匹配的分支列表。 这适用于前面的令牌以及嵌入的令牌。
（Zshell 对于命令完成是非常可配置的，我还可以将其配置为以相同的方式处理破折号、下划线或点。但我选择不这样做。）
它还允许您在许多 git 命令中搜索分支，如下所示：
Caveat: As Slipp 在评论中指出，斜线可能会导致问题。 因为分支是作为路径实现的，所以不能有一个名为“foo”的分支和另一个名为“foo/bar”的分支。 这可能会让新用户感到困惑。
不要使用裸数字
不要使用裸数字（或十六进制数字）作为分支命名方案的一部分。 在引用名称的制表符扩展内，git 可能会决定数字是 sha-1 的一部分，而不是分支名称的一部分。 例如，我的问题跟踪器用十进制数字命名错误。 为了避免混淆，我将相关分支命名为 CRnnnnn 而不仅仅是 nnnnn。
如果我尝试仅扩展 15032，git 将不确定我是否要搜索 SHA-1 还是分支名称，并且我的选择会受到一定限制。
避免长描述性名称
当您查看分支列表时，长分支名称非常有帮助。 但是，在查看经过修饰的单行日志时，它可能会造成妨碍，因为分支名称会占用单行的大部分内容并缩写日志的可见部分。
另一方面，如果您不习惯手动重写长分支名称，那么长分支名称在“合并提交”中可能会更有帮助。 默认合并提交消息是
Mergebranch 'branch-name'。 您可能会发现将合并消息显示为Mergebranch 'fix/CR15032/crash-when-unformatted-disk-inserted'而不仅仅是Mergebranch'fix/CR15032' 更有帮助。Here are some branch naming conventions that I use and the reasons for them
Branch naming conventions
Group tokens
Use "grouping" tokens in front of your branch names.
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:
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.
You can quickly tell which branches have reached each different stage, and you can group them together easily using Git's pattern matching options.
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.
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.
(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:
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.
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 asMerge branch 'fix/CR15032/crash-when-unformatted-disk-inserted'instead of justMerge branch 'fix/CR15032'.Vincent Driessen 的 成功的 Git 分支模型 提供了很好的建议。 下面是一张图片。 如果这种分支模型对您有吸引力，请考虑git 流程扩展。 其他人对流程进行了评论
Driessen 的模型包括
A master分支，仅用于发布。 典型名称
master。该分支的“开发”分支。 这是大多数主线工作所使用的。 通常称为
develop。开发分支有多个功能分支。 基于功能名称的名称。 这些将被合并回开发分支，而不是合并到主分支或发布分支中。
发布分支用于保存候选版本，仅修复错误，没有新功能。 典型名称
rc1.1。修补程序是来自 master 的更改的短期分支，并且将进入 master 而不涉及开发分支。
A successful Git branching model by 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
Driessen's model includes
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.Hotfixes are short-lived branches for changes that come from master and will go into master without development branch being involved.
我根据我所见过的不同方案并基于我正在使用的工具进行了混合和匹配。
所以我完成的分支名称是：
将翻译为：
这些部分用正斜杠分隔，因为这些部分在 SourceTree 中被解释为文件夹以便于组织。 我们使用 Jira 进行问题跟踪，因此包含该编号可以更轻松地在系统中查找。 当尝试提交拉取请求时，在 Github 中查找该问题时，包含该编号还可以使其可搜索。
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:
which would translate to:
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.
我个人的偏好是在完成主题分支后删除分支名称。
我没有尝试使用分支名称来解释分支的含义，而是在该分支上的第一次提交中以“Branch:”开始提交消息的主题行，并在消息正文中包含进一步的解释（如果主题）没有给我足够的空间。
我使用的分支名称纯粹是在处理主题分支时引用它的句柄。 一旦主题分支的工作结束，我就会删除分支名称，有时会标记提交以供以后参考。
这使得 gitbranch 的输出也更有用：它只列出长期存在的分支和活动主题分支，而不是所有分支。
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.
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.为什么每个任务都需要三个分支/合并？ 你能解释一下吗？
如果您使用错误跟踪系统，您可以使用错误号作为分支名称的一部分。 这将使分支名称保持唯一，并且您可以在它们前面添加一两个简短的描述性单词以使其易于阅读，例如
“ResizeWindow-43523”。 当您去清理分支时，它还可以让事情变得更容易，因为您可以查找相关的错误。 这就是我通常命名我的分支的方式。由于这些分支最终会合并回主分支，因此您应该在合并后安全地删除它们。 除非您与
--squash合并，否则分支的整个历史记录在您需要时仍然存在。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.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.请注意，如 commit e703d7 或 commit b6c2a0d（2014 年 3 月），现在是 Git 2.0 的一部分，您会发现另一个命名约定（可以应用于分支）。
分支名称不能包含空格（请参阅“分支名称中哪些字符是非法的？”和
git check-ref-format手册页）。因此，对于由多字表达式表示的每个分支名称，使用“
-”（破折号）作为分隔符是一个好主意。Note, as illustrated in the commit e703d7 or commit b6c2a0d (March 2014), now part of Git 2.0, you will find another naming convention (that you can apply to branches).
A branch name cannot have space (see "Which characters are illegal within a branch name?" and
git check-ref-formatman page).So for every branch name that would be represented by a multi-word expression, using a '
-' (dash) as a separator is a good idea.根据 farktronix 的建议，我们一直在 Mercurial 中使用 Jira 票号进行类似的操作，我计划继续使用它们用于 git 分支。 但我认为票号本身可能足够独特。 正如 Farktronix 指出的那样，虽然在分支名称中包含描述性单词可能会有所帮助，但如果您经常在分支之间切换，则可能需要更少的输入。 然后，如果您需要知道分支名称，请在 Jira 中查找工单中的关联关键字（如果您不知道）。 此外，您应该在每条评论中包含票号。
如果您的分支代表一个版本，则常见约定是使用 xxx（例如：“1.0.0”）格式作为分支名称，使用 vx.xx（例如“v1.0.0”）作为标记名称（以避免冲突） 。 另请参阅： is-there-an-standard-naming-convention -for-git-tags
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.
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