3

Are there any limitations to create branches in GitHub/GitLab?

I am currenly working on a project, so that I am curious about creation of branches. How many branches can be created ?

abinash_123_
  • 47
  • 1
  • 9

2 Answers2

10

There is no hard limit on the number of branches, tags, remote-tracking names, and other references. (All of Git's name-to-hash-ID map entries are refs or references: branch names are just refs whose full name starts with refs/heads/).

These are not always stored in separate files. In particular, refs will become "packed" over time. Packed refs live in one flat file, which makes them take (much) less disk space, though now reading any one particular ref's value—its hash ID—may involve reading a fairly large file, if you have many refs. (Writing the value causes the ref to become unpacked, leaving the previous value behind in the packed-refs file—so as you can see, the process of finding a ref's value starts by looking for the unpacked copy first, as that must override any packed copy.)

Since each name-and-value-pair occupies so little disk space (one block or less), it's definitely possible to create millions of refs. If you do this, though, your Git operations will slow down noticeably. The reason is that Git is full of linear scans through all refs. For instance, to "decorate" git log output,1 before git log prints a commit, it looks through every ref to see if that ref refers to that commit. The question to which rootkonda's answer links has, in qqx's answer, another link to a nabble.com archived mailing list thread about performance issues that occur (some are fixed already, some remain).

GitHub and Google also both discovered some years ago that Git can spend a lot of time and network bandwidth in the greeting process that two Gits go through at startup, too: when you have your Git call up a server's Git for git fetch for instance, your Git has the server Git list out all of its branch and tag and other such names. If there are, say ten thousand listed names, each an average of about 60 characters long when expanded with hash IDs,2 that's about 600 kilobytes of data transfer before any useful commit exchanges can occur.

In general, it's not a good plan to create thousands or millions of refs. There's no theoretical reason not to do it but for protocol and performance reasons, a soft cap of under a thousand refs might be advisable.

1In:

commit c7a62075917b3340f908093f63f1161c44ed1475 (HEAD -> master, origin/master, origin/HEAD)

the HEAD, master, origin master, and origin/HEAD are decorations found by searching all refs; the HEAD -> formatting indicates that HEAD is attached, in this case to master).

2Note that annotated tags get doubled here, as they list both the tag name and hash ID, and the tag name suffixed with ^{} and tag's target. refs/tags/v1.2.3 09e393d913072d7765b02aba1210d843a83cfbae is 57 characters even without a newline or other separator.

torek
  • 448,244
  • 59
  • 642
  • 775
2

By default there is no limit to the size of pack files, although git gets a bit sluggish if they are too large to fit nicely in memory. Git also has branches. Each branch is simply a text file that stores the 40-byte sha1 of the commit. Therefore, each branch takes up 40 bytes (but really, 4.0KB on disk).

For more info, you can read this link: Limit on number of git branches

rootkonda
  • 1,700
  • 1
  • 6
  • 11
  • Thank you, It means we can create millions of branches. – abinash_123_ Feb 17 '20 at 15:13
  • 1
    Ideally you dont need to. Generally we use branches until its merged to trunk or some of them you leave it as is because it has different config. But I don't think we will hit that extreme scenario. But yes, good to know the fact :) – rootkonda Feb 17 '20 at 15:16
  • @abinash_123_ I'd be fascinated to know what you're doing that needs millions of branches. Would you mind posting it as a question? Something like "We have this problem and we're going to solve it by making millions of Git branches, is there a better solution?" – Schwern Feb 17 '20 at 15:58