命名git分支的常用做法有哪些例子? [英] What are some examples of commonly used practices for naming git branches?
问题描述
几个月来，我一直在使用本地git存储库与小组的CVS存储库进行交互.我已经做出了几乎神经质的分支，幸运的是，其中大多数已经合并回了我的树干.但是命名已经开始成为一个问题.如果我有一个用简单标签轻松命名的任务，但是我分三个阶段完成任务，每个阶段都包括自己的分支和合并情况，那么我可以每次重复分支名称，但这会使历史有些混乱.如果我在名称上更加具体，并且每个阶段都有单独的描述，则分支名称开始变得冗长而笨拙.
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.
命名git分支的最佳做法是什么?
What are some best practices for naming git branches?
实际上，没有人建议任何命名约定. 处理完分支后，我确实会删除它们.由于管理人员不断调整我的工作重点，所以我碰巧遇到了一些情况. :) 作为一个为什么我可能在一个任务上需要多个分支的示例，假设我需要将该任务中的第一个离散里程碑提交到组的CVS存储库.到那时，由于我与CVS的互动不完善，我将执行该提交，然后终止该分支. (如果我尝试在那一刻继续使用同一分支，我已经看到与CVS交互的怪异之处.)
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
分支命名约定
- 在分支名称的开头使用分组标记(单词).
- 以对您的工作流程有意义的方式定义和使用短前导令牌来区分分支.
- 使用斜杠分隔分支名称的一部分.
- 请勿将裸数字用作开头部分.
- 避免为长期存在的分支使用长的描述性名称.
组令牌
在分支机构名称前使用分组"标记.
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.
简短定义的令牌
选择短标记，以免对您的每个分支名称都增加过多的干扰.我用这些:
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
您可以快速判断出哪个分支已经到达每个不同的阶段，并且可以使用Git的模式匹配选项轻松地将它们分组在一起.
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"
使用斜杠分隔各个部分
您可以在分支名称中使用大多数喜欢的定界符，但是我发现斜杠是最灵活的.您可能更喜欢使用破折号或点.但是，使用斜杠可以使您在向/从远程推入或从远程取回时进行一些分支重命名.
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/*'
对我来说，斜线还可以更好地在我的shell中进行制表符扩展(命令完成).配置方式可以通过键入零件的第一个字符并按TAB键来搜索具有不同子零件的分支.然后，Zsh给我一个与我输入的令牌部分匹配的分支列表.这适用于先前的令牌和嵌入式令牌.
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在命令完成方面具有很高的可配置性，我也可以将其配置为以相同的方式处理破折号，下划线或点.但我选择不这样做.)
(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.)
它还允许您在许多git命令中搜索分支，例如:
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/*"
注意事项:正如Slipp在评论中指出的那样，斜线可能会引起问题.因为分支是作为路径实现的，所以不能有一个名为"foo"的分支和另一个名为"foo/bar"的分支.这可能会使新用户感到困惑.
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.
请勿使用空号
请勿在分支命名方案中使用裸数字(或十六进制数字).在参考名称的制表符扩展内，git可能会确定数字是sha-1的一部分，而不是分支名称.例如，我的问题跟踪器使用十进制数字命名错误.为了避免混淆，我将相关分支命名为CRnnnnn而不是nnnnn.
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
如果我尝试仅扩展15032，则git不确定是要搜索SHA-1的名称还是分支名称，并且我的选择会受到一定限制.
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.
避免使用冗长的描述性名称
在查看分支列表时，长分支名称可能会非常有帮助.但是在查看修饰的单行日志时可能会遇到麻烦，因为分支名称会占用大部分单行并缩写日志的可见部分.
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.
另一方面，如果您不习惯手工重写长分支名称，则在合并提交"中会更有用.默认的合并提交消息为Merge branch 'branch-name'.您可能会发现使合并消息显示为Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted'而不是仅显示为Merge branch 'fix/CR15032'更为有用.
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屋！
