git - 有哪些常用的命名git分支实例的例子？ [关闭](What are some examples of commonly used practices for naming git branches? [closed])

Question

I've been using a local git repository interacting with my group's CVS repository for several months, now.

(现在，我已经使用本地git存储库与我的组的CVS存储库进行了几个月的交互。)

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, ie, 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.

(:)作为为什么我可能需要在任务上需要多个分支的示例，假设我需要将任务中的第一个离散里程碑提交到组的CVS存储库。)

At that point, due to my imperfect interaction with CVS, I would perform that commit and then kill that branch.

(那时，由于我与CVS的不完美交互，我会执行该提交然后杀死该分支。)

(I've seen too much weirdness interacting with CVS if I try to continue to use the same branch at that point.)

(（如果我在这一点上尝试继续使用相同的分支，我看到太多奇怪的事情与CVS交互。）)

  ask by skiphoppy translate from so

Answer 1

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

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

(对我来说，斜杠也可以更好地用于我的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.

(我配置它的方式我可以通过键入部件的第一个字符并按TAB键来搜索具有不同子部件的分支。)

Zsh then gives me a list of branches which match the part of the token I have typed.

(Zsh然后给我一个分支列表，它与我输入的令牌部分相匹配。)

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

(（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.

(警告：正如Slipp在评论中指出的那样，斜线可能会导致问题。)

Because branches are implemented as paths, you cannot have a branch named "foo" and another branch named "foo/bar".

(因为分支是作为路径实现的，所以不能有名为“foo”的分支和名为“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.

(在引用名称的制表符扩展内，git可以决定数字是sha-1的一部分而不是分支名称。)

For example, my issue tracker names bugs with decimal numbers.

(例如，我的问题跟踪器使用十进制数字命名错误。)

I name my related branches CRnnnnn rather than just nnnnn to avoid confusion.

(我将我的相关分支命名为CRnnnn而不仅仅是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' .

(默认的合并提交消息是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 'fix/CR15032/crash-when-unformatted-disk-inserted'而不仅仅是Merge branch 'fix/CR15032' 。)