在GitHub / GitLab中创建分支有任何限制吗？
我目前正在从事一个项目，所以我对创建分支感到好奇。 可以创建多少个分支？
答案 0 :(得分：1)
默认情况下，打包文件的大小没有限制，尽管如果git太大而无法很好地容纳在内存中，则git会变慢。 Git也有分支。每个分支只是一个文本文件，其中存储了40字节的提交sha1。因此，每个分支占用40个字节（但实际上在磁盘上为4.0KB）。
有关更多信息，您可以阅读以下链接：Limit on number of git branches
答案 1 :(得分：0)
分支，标签，远程跟踪名称和其他引用的数量没有硬性限制。 （所有Git的名称到哈希ID的映射条目都是 refs 或 references：分支名称只是其全名以refs/heads/开头的refs。）。 / p>
这些不是总是 存储在单独的文件中。特别是，裁判将随着时间的流逝而变得“挤满”。打包的引用驻留在一个平面文件中，这使它们占用的磁盘空间少得多，尽管现在读取任何一个特定引用的值（其哈希ID）可能涉及读取相当大的文件（如果您有很多引用）。 （ Writing 的值会导致ref变得未打包，而将先前的值保留在packed-refs文件中。因此，如您所见，查找ref的值的过程首先是查找未打包的副本首先，因为它必须覆盖所有打包副本。）
由于每个名称和值对占用的磁盘空间很小（一个块或更少），因此绝对有可能创建数百万个引用。但是，如果执行此操作，您的Git操作将明显变慢。原因是Git充满了对所有ref的线性扫描。例如，要“装饰” git log输出，请在git log打印提交之前先 1 打印提交，它会遍历每个引用以查看该引用是否引用了该提交。 question链接到的rootkonda's answer在qqx's answer中有另一个指向nabble.com archived mailing list thread的链接，这些链接涉及发生的性能问题（有些已经解决，有些仍然存在）。
GitHub和Google也在几年前都发现，Git在启动两个Git的问候过程中也会花费大量时间和网络带宽：当您的Git为{{ 1}}，例如，您的Git服务器Git列出了其分支和标记的 all 以及其他此类名称。如果有上万个列出的名称，则在使用哈希ID扩展时，每个名称平均平均长约60个字符， 2 表示在进行任何有用的提交之前，数据传输量大约为600 KB。可能会发生交换。
通常，创建数千或数百万个引用不是一个好计划。没有理论上的理由不这样做，但是出于协议和性能的原因，建议将参考数量限制在1000个以下。
1 在：
git fetch commit c7a62075917b3340f908093f63f1161c44ed1475 (HEAD -> master, origin/master, origin/HEAD)
，HEAD，master和origin master是通过搜索所有引用找到的装饰。 origin/HEAD格式表示附加了HEAD ->，在这种情况下是HEAD）。
2 请注意，带注释的标签在此会加倍，因为它们同时列出了标签名称和哈希ID，以及带有master后缀的标签名称和标签的目标。即使没有换行符或其他分隔符，^{}仍为57个字符。