I don't know if it is possible to do such a thing.

I'll explain with an example what I mean.

I have a repository on github for example.

A user comes in and forks my repository, creates a new branch, then makes changes.

I would like to do that locally, so on my pc, on the same repository as the original one with my branches, add the user's branch, without having to clone the repository.

Is there a way to add/download that branch and add it to my repository, so that I can try it out?

CodePudding user response：

Is there a way to add/download that branch and add it to my repository, so that I can try it out?

Sure! First, add a remote to your local repository pointing at the fork. E.g., if you repository was named example and I had forked it, you would run:

git remote add larsks https://github.com/larsks/example

That command creates a remote named larsks pointing at my fork (you can name the remote anything you want, but I usually use the github username). Now, update the local cache for that remote:

git remote update

And now you can see branches in that fork and check them out locally. To access my main branch, you would run:

git checkout larsks/main

Or to access my feature1 branch:

git checkout larsks/feature1

Etc. Note that the above commands will put you in a "detached head" state; to check out a local branch based on one of those branches you might run something like:

git checkout -b feature1 larsks/feature1

CodePudding user response：

TL;DR

• run git remote add
• run git fetch
• profit!

Long

The bottom line is that you need to copy their commits. You do not need to copy their "branch" unless, by the word "branch", you mean "the set of commits in question".

... without having to clone the repository

The act of copying commits is "cloning". Or is it? The word isn't all that well defined: when we clone a repository, we copy all of its commits—or at least, all of the ones we want to copy: those that we care about and are new to us.

The git clone command, on the other hand, means:

• make a new empty repository;
• add a remote (a short name by which we'll contact some other Git repository, probably repeatedly, in the future);
• copy their commits; and
• create an initial branch name, since working without a branch name is no fun.

(Git doesn't actually need any branch names at all, but see "no fun".) So you don't want to run git clone, because you don't want step 1 here: you want to use your existing repository. But you do want steps 2 and 3, and then you may or may not want a variation on the last step.

Fortunately, we have:

• git remote add: this is how we add a remote to a repository, and in fact, git clone essentially uses git remote add to set up origin so that you can run git fetch origin; and
• git fetch remote: this is how we copy some other repository's commits, or at least, those that we find interesting and are new to us.

The git pull command, if you use it—I recommend avoiding it, especially if you're new to Git—consists of running git fetch followed by running a second Git command, to do something with the just-fetched commits if any. Split this up into the two separate commands so that you will learn and understand each of the two steps, and thereby profit (see the TL;DR section).

The git fetch command calls up one specific remote, using the URL saved during git remote add. Your Git software and their Git software—"they" being whoever answers at that URL—converse, to figure out which commits you have and which ones they have. Then your Git software downloads the new-to-you commits. When we run git clone, all the commits are new to us, so we get them all, but when we run git fetch, we get a much more limited set, which goes a lot faster.

Once you have more than one remote, things get a little trickier than when you have just one. The git fetch command needs to know which remote to use. If you run it without any arguments, it guesses. If all else fails it just guesses origin, which is the standard First Name For A Remote.

Running git remote update tells your Git software to run git fetch to all remotes. More precisely, it fetches from a defined set of remotes, or a group, but the default here is "all". You can do the same with git fetch --all: the --all here means all remotes.

As for branch names: Git uses these to help you (and Git) find your own commits. When you fetch from some other repository, Git creates or updates names in your own repository that I call remote-tracking names. These are not branch names—even though Git calls them remote-tracking branch names, they don't work the way branch names work. But you'll want one if you're going to make any new commits of your own.

When you run, e.g.:

git checkout foobranch    # or git switch foobranch

and there is no branch named foobranch in your set of branches, your own Git software would—and will if you add --no-guess here—complain that there is no foobranch, and just fail. But if you let Git use --guess, which is the default setting, your Git will scan your remote-tracking names, to look for origin/foobranch and—if there's a remote2—remote2/foobranch and so on. If it finds exactly one match it will "guess" that you meant create a new branch with name foobranch using the commit found by the remote-tracking name.

Once you have two remotes, this guess mode stops working so well. Just be aware of this.