1

I was reading this blog and got to know about

git remote add -t <remoteBranchName> -f origin <remoteRepoUrlPath>

According to the blog, this command clones the specified remote branch. But why would someone clone just a branch? I want to know about the circumstances that would need someone to clone just a branch?

Any insights would be highly appreciated, thanks in advance!!

Shreemaan Abhishek
  • 1,134
  • 1
  • 7
  • 33

2 Answers2

1

I would say there are at least 3 reasons:

  • A CI server generally does not need to checkout the whole repository in order to run a pipeline. I am thinking about multi-branch pipelines for example, where a pipeline is customized based on the branch that triggered the build.
  • The repository could take minutes to be cloned, especially in projects where many developers are experimenting new features (that I assume to be branches)
  • If you know you are going to work on a specific branch, why do you need the others? Just that. Stupid example: I have a git alias showing me the graphs of all branches, but most of the times I am only interested in the one I am working on. If you repo contains many branches it is more likely to make a mistake when running scripts of git commands.
Marco Luzzara
  • 5,540
  • 3
  • 16
  • 42
0

There is never1 a need to do this.

People sometimes want to do this, often due to misunderstandings (they think that Git branches matter more than they actually do). Your first reaction to seeing this should be: I don't want to do that.

A so-called single-branch clone, in Git, means that git fetch operations ignore all but the one branch name, and only bring over any commits required to satisfy the tip commit of that branch. If your repository is not a shallow repository, though, this usually means bringing over almost every commit anyway, i.e., there is usually very little time and space savings from making single-branch clones. There are exceptions to this rule (see footnote 1) and if you actually do get significant savings, you can go ahead and do it.

You generally save a great deal more time and space with what Git calls a shallow clone, though. So instead of, or in addition to, a single-branch clone, you might want to create a shallow clone. The --depth argument to git clone creates a shallow, single-branch clone by default.

Shallow clones have some limitations, but most of the nasty ones (such as the inability to use git push from one) were removed long ago. Since a shallow clone is a single-branch clone by default, it's a good idea to know what single-branch clones do.

With any clone, try running:

git ls-remote

(this command only prints stuff, it never does anything to your repository). You'll see that the other Git that your Git calls up lists out all of its branch and tag names and the corresponding hash IDs. This gives your Git the ability to ask for all the commits that they have, and to create or update remote-tracking names for each of their branch names. If you don't want all of that, you can eliminate most of these remote-tracking names. This speeds some things up.2 Also, by not asking for some of their commits, you can avoid getting all of their commits—although, again, shallow clones are far more effective at making sure you don't get all of their commits.

1Insert Gilbert & Sullivan routine here. There are some special cases, e.g., when it's known that branch X never contains commits that have big files and branch Y contains commits that do have big files and there's not enough room on the local disk for the big files. But "because it's faster/smaller" is not a physical requirement, it's just impatience. :-) See the rest of the above, about shallow clones, for more.

2While git ls-remote will, necessarily, ask their Git about all their branches, some fairly recent work makes some versions of Git a bit smarter, so that if you have a single-branch clone, or an N-branch clone with some small value of N, your Git can tell their Git that you don't need every branch and tag name. In some repositories—such as that for Google's Chrome—there are so many branch and tag names that this savings alone is noticeable.

For this to work, both Gits—yours and the remote one—must be fairly modern. Git 1.x is right out.

torek
  • 448,244
  • 59
  • 642
  • 775
  • By `your git` and `their git` do you mean to say `your repo` and `their repo`? I'm quite unable to understand this thing. – Shreemaan Abhishek Aug 03 '21 at 05:17
  • Your command-line `git` command manipulates—in the `git clone` case case, *creates* then manipulates—your repository. Your Git calls up another, separate `git` command, on the server, which talks to (reads from or, for `git push`, writes to) their repository. – torek Aug 03 '21 at 05:19
  • So, by *your Git*, I mean your suite of Git commands, running cooperatively on your computer, working with your files in your file systems, and so on. *Their Git* refers to the same thing, but happening on *their* computer. (SIde note: this is a more literal version of something that often happens figuratively in English. See https://www.merriam-webster.com/words-at-play/synecdoche-metonymy-usage-differences) – torek Aug 03 '21 at 05:21