到目前为止，我已经使用本地git存储库与我的团队的CVS存储库进行了几个月的交互。我已经做了大量的树枝，谢天谢地，它们中的大多数已经并入了我的树干。但命名开始成为一个问题。如果我有一个任务很容易用一个简单的标签命名，但我分三个阶段完成它，每个阶段都包括自己的分支和合并情况，那么我可以每次重复分支名称，但这会使历史记录有点混乱。如果我的名称更加具体，每个阶段都有单独的描述，那么分支名称就会变得冗长而笨拙。
我确实从这里的旧线程中了解到，我可以开始在名称中使用/来命名分支，即主题/任务，或类似的东西。我可能会开始这样做，看看它是否有助于让事情更有条理。
命名git分支的最佳实践是什么?
编辑: 实际上没有人建议任何命名约定。 当我用完分支时，我会删除它们。由于管理层不断调整我的优先级，我刚好有几个。：） 为了说明为什么一个任务可能需要多个分支，假设我需要将任务中的第一个离散里程碑提交到组的CVS存储库。此时，由于与CVS的交互不完美，我将执行该提交，然后终止该分支。(如果我尝试继续使用同一个分支，我就会看到太多与CVS交互的奇怪之处。)
当前回答
Vincent Driessen的一个成功的Git分支模型有很好的建议。下面是一幅图片。如果您喜欢这个分支模型，可以考虑对git进行流扩展。其他人对心流进行了评论
德里森的模型包括
一个主分支，仅用于发布。典型的名称管理员。 该分支的“开发”分支。这是最主要的工作方式。通常命名为develop。 开发分支的多个特性分支。根据特性的名称命名。这些将被合并回开发分支，而不是主分支或发布分支。 发布分支保存候选版本，只有错误修复，没有新特性。典型名称rc1.1。
热修复是短期的分支，用于来自主系统的更改，并且将在不涉及开发分支的情况下进入主系统。
其他回答
为什么每个任务需要三个分支/合并?你能详细解释一下吗?
如果您使用bug跟踪系统，您可以将bug编号作为分支名称的一部分。这将保持分支名称的唯一性，您可以在它们前面加上一两个简短的描述性单词来保持它们的可读性，比如“ResizeWindow-43523”。当您清理分支时，它还有助于简化工作，因为您可以查找相关的错误。这就是我通常如何命名我的分支。
因为这些分支最终会被合并回主系统，所以在合并后删除它们应该是安全的。除非合并-squash，否则分支的整个历史将仍然存在，如果您需要它的话。
我已经根据所见过的不同方案和所使用的工具进行了混合和匹配。 所以我的完整分支名称将是:
名称/功能/ issue-tracker-number /简短描述
这将转化为:
迈克/博客/ RSSI-12 / logo-fix
这些部分由正斜杠分隔，因为这些部分被解释为SourceTree中的文件夹，以便于组织。我们使用Jira来跟踪我们的问题，所以包括数字可以更容易地在系统中查找。包括这个数字也使它可以在试图提交拉请求时在Github中找到这个问题。
下面是我使用的一些分支命名约定及其原因
分支命名约定
在分支名称的开头使用分组标记(单词)。 定义和使用短引线标记，以对您的工作流有意义的方式区分分支。 使用斜杠分隔分支名称的各个部分。 不要用数字作为开头部分。 避免为长生命周期的分支使用冗长的描述性名称。
集团的令牌
在分支名称前使用“分组”标记。
group1/foo
group2/foo
group1/bar
group2/bar
group3/bar
group1/baz
这些组可以根据您的工作流程任意命名。我喜欢用简短的名词来称呼我的名字。读下去会更清楚。
定义良好的短标记
选择简短的标记，这样它们就不会给每个分支名称添加太多的干扰。我用这些:
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
每个令牌都可以用来告诉您每个分支属于工作流的哪个部分。
听起来您有多个分支用于不同的变更周期。我不知道你的周期是什么，但让我们假设它们是“新的”、“测试中的”和“已验证的”。您可以使用这些标记的缩写版本来命名分支，始终以相同的方式拼写，以便对它们进行分组并提醒您处于哪个阶段。
new/frabnotz
new/foo
new/bar
test/foo
test/frabnotz
ver/foo
您可以快速判断哪些分支已经达到了每个不同的阶段，并且可以使用Git的模式匹配选项轻松地将它们组合在一起。
$ git branch --list "test/*"
test/foo
test/frabnotz
$ git branch --list "*/foo"
new/foo
test/foo
ver/foo
$ gitk --branches="*/foo"
使用斜杠分隔部分
您可以在分支名称中使用任何您喜欢的分隔符，但我发现斜杠是最灵活的。你可能更喜欢用破折号或圆点。但是，斜杠可以让您在推送或从远程获取时进行一些分支重命名。
$ git push origin 'refs/heads/feature/*:refs/heads/phord/feat/*'
$ git push origin 'refs/heads/bug/*:refs/heads/review/bugfix/*'
对我来说，斜杠在我的shell中更适用于tab扩展(命令补全)。我有它配置的方式，我可以通过输入部分的第一个字符并按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是非常可配置的命令补全，我也可以配置它以同样的方式处理破折号，下划线或点。但我选择不去。)
它还允许你在许多git命令中搜索分支，像这样:
git branch --list "feature/*"
git log --graph --oneline --decorate --branches="feature/*"
gitk --branches="feature/*"
警告:正如Slipp在评论中指出的那样，斜杠可能会导致问题。因为分支是作为路径实现的，你不能有一个名为“foo”的分支和另一个名为“foo/bar”的分支。这可能会让新用户感到困惑。
不要使用裸数字
不要使用裸数字(或十六进制数字)作为分支命名方案的一部分。在引用名称的制表符扩展中，git可能会决定一个数字是sha-1的一部分，而不是分支名称。例如，我的问题跟踪器用十进制数字命名bug。为了避免混淆，我将相关分支命名为CRnnnnn而不是nnnnn。
$ git checkout CR15032<TAB>
Menu: fix/CR15032 test/CR15032
如果我尝试只扩展15032,git将不确定我是想搜索SHA-1的名称还是分支名称，并且我的选择将受到一定的限制。
避免使用冗长的描述性名称
在查看分支列表时，较长的分支名称非常有用。但是，当查看经过修饰的单行日志时，分支名称可能会占用大部分单行，并缩短日志的可见部分。
另一方面，如果您不习惯手工重写，那么长分支名称在“合并提交”中会更有帮助。默认的合并提交消息是合并分支'branch-name'。你可能会发现，让合并消息显示为合并分支'fix/CR15032/crash-when- unformatting -disk-inserted'而不是合并分支'fix/CR15032'更有帮助。
Vincent Driessen的一个成功的Git分支模型有很好的建议。下面是一幅图片。如果您喜欢这个分支模型，可以考虑对git进行流扩展。其他人对心流进行了评论
德里森的模型包括
一个主分支，仅用于发布。典型的名称管理员。 该分支的“开发”分支。这是最主要的工作方式。通常命名为develop。 开发分支的多个特性分支。根据特性的名称命名。这些将被合并回开发分支，而不是主分支或发布分支。 发布分支保存候选版本，只有错误修复，没有新特性。典型名称rc1.1。
热修复是短期的分支，用于来自主系统的更改，并且将在不涉及开发分支的情况下进入主系统。
根据farktronix的建议，我们一直在为类似的mercurial使用Jira票号，我计划继续在git分支中使用它们。但我认为票号本身可能已经足够独特了。正如farktronix指出的那样，在分支名称中使用描述性单词可能会有所帮助，但如果您经常在分支之间切换，则可能希望少输入一些内容。然后，如果您需要知道分支名称，如果您不知道，可以在Jira中查找票据中相关的关键字。此外，您应该在每个注释中包含票号。
如果您的分支代表一个版本，那么通常的约定是使用x.x.x(例如“1.0.0”)格式作为分支名称，使用vx.x.x(例如“v1.0.0”)格式作为标记名称(以避免冲突)。参见:is-there-an-standard-naming-convention-for-git-tags
