到目前为止，我已经使用本地git存储库与我的团队的CVS存储库进行了几个月的交互。我已经做了大量的树枝，谢天谢地，它们中的大多数已经并入了我的树干。但命名开始成为一个问题。如果我有一个任务很容易用一个简单的标签命名，但我分三个阶段完成它，每个阶段都包括自己的分支和合并情况，那么我可以每次重复分支名称，但这会使历史记录有点混乱。如果我的名称更加具体，每个阶段都有单独的描述，那么分支名称就会变得冗长而笨拙。
我确实从这里的旧线程中了解到，我可以开始在名称中使用/来命名分支，即主题/任务，或类似的东西。我可能会开始这样做，看看它是否有助于让事情更有条理。
命名git分支的最佳实践是什么?
编辑: 实际上没有人建议任何命名约定。 当我用完分支时，我会删除它们。由于管理层不断调整我的优先级，我刚好有几个。：） 为了说明为什么一个任务可能需要多个分支，假设我需要将任务中的第一个离散里程碑提交到组的CVS存储库。此时，由于与CVS的交互不完美，我将执行该提交，然后终止该分支。(如果我尝试继续使用同一个分支，我就会看到太多与CVS交互的奇怪之处。)
当前回答
为什么每个任务需要三个分支/合并?你能详细解释一下吗?
如果您使用bug跟踪系统，您可以将bug编号作为分支名称的一部分。这将保持分支名称的唯一性，您可以在它们前面加上一两个简短的描述性单词来保持它们的可读性，比如“ResizeWindow-43523”。当您清理分支时，它还有助于简化工作，因为您可以查找相关的错误。这就是我通常如何命名我的分支。
因为这些分支最终会被合并回主系统，所以在合并后删除它们应该是安全的。除非合并-squash，否则分支的整个历史将仍然存在，如果您需要它的话。
其他回答
我已经根据所见过的不同方案和所使用的工具进行了混合和匹配。 所以我的完整分支名称将是:
名称/功能/ issue-tracker-number /简短描述
这将转化为:
迈克/博客/ RSSI-12 / logo-fix
这些部分由正斜杠分隔，因为这些部分被解释为SourceTree中的文件夹，以便于组织。我们使用Jira来跟踪我们的问题，所以包括数字可以更容易地在系统中查找。包括这个数字也使它可以在试图提交拉请求时在Github中找到这个问题。
我个人倾向于在完成主题分支之后删除分支名称。
我没有尝试使用分支名称来解释分支的含义，而是在该分支上的第一次提交中以“branch:”开始提交消息的主题行，如果主题没有给我足够的空间，则在消息正文中包含进一步的解释。
我使用的分支名称纯粹是一个句柄，用于在处理主题分支时引用它。一旦主题分支的工作结束，我就会去掉分支名称，有时还会标记提交以供以后参考。
这也使得git分支的输出更有用:它只列出长生命周期的分支和活动的主题分支，而不是所有的分支。
注意，正如提交e703d7或提交b6c2a0d(2014年3月)(现在是Git 2.0的一部分)中所述，您将发现另一种命名约定(可以应用于分支)。
“当你需要使用空格时，使用破折号”是一种奇怪的说法，表示你不能使用空格。 因为命令行描述使用多字破折号更为常见，所以您甚至不希望在这些地方使用空格。
分支名称不能有空格(参见“分支名称中哪些字符是非法的?”和git check-ref-format手册页)。
因此，对于每个由多字表达式表示的分支名称，使用“-”(破折号)作为分隔符是个好主意。
Vincent Driessen的一个成功的Git分支模型有很好的建议。下面是一幅图片。如果您喜欢这个分支模型，可以考虑对git进行流扩展。其他人对心流进行了评论
德里森的模型包括
一个主分支，仅用于发布。典型的名称管理员。 该分支的“开发”分支。这是最主要的工作方式。通常命名为develop。 开发分支的多个特性分支。根据特性的名称命名。这些将被合并回开发分支，而不是主分支或发布分支。 发布分支保存候选版本，只有错误修复，没有新特性。典型名称rc1.1。
热修复是短期的分支，用于来自主系统的更改，并且将在不涉及开发分支的情况下进入主系统。
为什么每个任务需要三个分支/合并?你能详细解释一下吗?
如果您使用bug跟踪系统，您可以将bug编号作为分支名称的一部分。这将保持分支名称的唯一性，您可以在它们前面加上一两个简短的描述性单词来保持它们的可读性，比如“ResizeWindow-43523”。当您清理分支时，它还有助于简化工作，因为您可以查找相关的错误。这就是我通常如何命名我的分支。
因为这些分支最终会被合并回主系统，所以在合并后删除它们应该是安全的。除非合并-squash，否则分支的整个历史将仍然存在，如果您需要它的话。
