Set as tracked branch что значит

jgregorio0 / git-no-tracked-branch

This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters

// Open Git bash in folder

git checkout master

git branch —set-upstream-to=origin/master

// Otherwise execute fetch

jgregorio0 commented Nov 20, 2016

Can't update: no tracked branch No tracked branch configured for branch master. To make your branch track a remote branch call, for example, git branch --set-upstream master origin/master (show balloon) 

3.5 Git Branching — Remote Branches

Remote references are references (pointers) in your remote repositories, including branches, tags, and so on. You can get a full list of remote references explicitly with git ls-remote , or git remote show for remote branches as well as more information. Nevertheless, a more common way is to take advantage of remote-tracking branches.

Remote-tracking branches are references to the state of remote branches. They’re local references that you can’t move; Git moves them for you whenever you do any network communication, to make sure they accurately represent the state of the remote repository. Think of them as bookmarks, to remind you where the branches in your remote repositories were the last time you connected to them.

Remote-tracking branch names take the form / . For instance, if you wanted to see what the master branch on your origin remote looked like as of the last time you communicated with it, you would check the origin/master branch. If you were working on an issue with a partner and they pushed up an iss53 branch, you might have your own local iss53 branch, but the branch on the server would be represented by the remote-tracking branch origin/iss53 .

This may be a bit confusing, so let’s look at an example. Let’s say you have a Git server on your network at git.ourcompany.com . If you clone from this, Git’s clone command automatically names it origin for you, pulls down all its data, creates a pointer to where its master branch is, and names it origin/master locally. Git also gives you your own local master branch starting at the same place as origin’s master branch, so you have something to work from.

“origin” is not special

Just like the branch name “master” does not have any special meaning in Git, neither does “origin”. While “master” is the default name for a starting branch when you run git init which is the only reason it’s widely used, “origin” is the default name for a remote when you run git clone . If you run git clone -o booyah instead, then you will have booyah/master as your default remote branch.

Figure 30. Server and local repositories after cloning

If you do some work on your local master branch, and, in the meantime, someone else pushes to git.ourcompany.com and updates its master branch, then your histories move forward differently. Also, as long as you stay out of contact with your origin server, your origin/master pointer doesn’t move.

Figure 31. Local and remote work can diverge

To synchronize your work with a given remote, you run a git fetch command (in our case, git fetch origin ). This command looks up which server “origin” is (in this case, it’s git.ourcompany.com ), fetches any data from it that you don’t yet have, and updates your local database, moving your origin/master pointer to its new, more up-to-date position.

Figure 32. git fetch updates your remote-tracking branches

To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let’s assume you have another internal Git server that is used only for development by one of your sprint teams. This server is at git.team1.ourcompany.com . You can add it as a new remote reference to the project you’re currently working on by running the git remote add command as we covered in Git Basics. Name this remote teamone , which will be your shortname for that whole URL.

Figure 33. Adding another server as a remote

Now, you can run git fetch teamone to fetch everything the remote teamone server has that you don’t have yet. Because that server has a subset of the data your origin server has right now, Git fetches no data but sets a remote-tracking branch called teamone/master to point to the commit that teamone has as its master branch.

Figure 34. Remote-tracking branch for teamone/master

Pushing

When you want to share a branch with the world, you need to push it up to a remote to which you have write access. Your local branches aren’t automatically synchronized to the remotes you write to — you have to explicitly push the branches you want to share. That way, you can use private branches for work you don’t want to share, and push up only the topic branches you want to collaborate on.

If you have a branch named serverfix that you want to work on with others, you can push it up the same way you pushed your first branch. Run git push :

$ git push origin serverfix Counting objects: 24, done. Delta compression using up to 8 threads. Compressing objects: 100% (15/15), done. Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done. Total 24 (delta 2), reused 0 (delta 0) To https://github.com/schacon/simplegit * [new branch] serverfix -> serverfix

This is a bit of a shortcut. Git automatically expands the serverfix branchname out to refs/heads/serverfix:refs/heads/serverfix , which means, “Take my serverfix local branch and push it to update the remote’s serverfix branch.” We’ll go over the refs/heads/ part in detail in Git Internals, but you can generally leave it off. You can also do git push origin serverfix:serverfix , which does the same thing — it says, “Take my serverfix and make it the remote’s serverfix.” You can use this format to push a local branch into a remote branch that is named differently. If you didn’t want it to be called serverfix on the remote, you could instead run git push origin serverfix:awesomebranch to push your local serverfix branch to the awesomebranch branch on the remote project.

Don’t type your password every time

If you’re using an HTTPS URL to push over, the Git server will ask you for your username and password for authentication. By default it will prompt you on the terminal for this information so the server can tell if you’re allowed to push.

If you don’t want to type it every single time you push, you can set up a “credential cache”. The simplest is just to keep it in memory for a few minutes, which you can easily set up by running git config —global credential.helper cache .

For more information on the various credential caching options available, see Credential Storage.

The next time one of your collaborators fetches from the server, they will get a reference to where the server’s version of serverfix is under the remote branch origin/serverfix :

$ git fetch origin remote: Counting objects: 7, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfix

It’s important to note that when you do a fetch that brings down new remote-tracking branches, you don’t automatically have local, editable copies of them. In other words, in this case, you don’t have a new serverfix branch — you have only an origin/serverfix pointer that you can’t modify.

To merge this work into your current working branch, you can run git merge origin/serverfix . If you want your own serverfix branch that you can work on, you can base it off your remote-tracking branch:

$ git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

This gives you a local branch that you can work on that starts where origin/serverfix is.

Tracking Branches

Checking out a local branch from a remote-tracking branch automatically creates what is called a “tracking branch” (and the branch it tracks is called an “upstream branch”). Tracking branches are local branches that have a direct relationship to a remote branch. If you’re on a tracking branch and type git pull , Git automatically knows which server to fetch from and which branch to merge in.

When you clone a repository, it generally automatically creates a master branch that tracks origin/master . However, you can set up other tracking branches if you wish — ones that track branches on other remotes, or don’t track the master branch. The simple case is the example you just saw, running git checkout -b / . This is a common enough operation that Git provides the —track shorthand:

$ git checkout --track origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

In fact, this is so common that there’s even a shortcut for that shortcut. If the branch name you’re trying to checkout (a) doesn’t exist and (b) exactly matches a name on only one remote, Git will create a tracking branch for you:

$ git checkout serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name:

$ git checkout -b sf origin/serverfix Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf'

Now, your local branch sf will automatically pull from origin/serverfix .

If you already have a local branch and want to set it to a remote branch you just pulled down, or want to change the upstream branch you’re tracking, you can use the -u or —set-upstream-to option to git branch to explicitly set it at any time.

$ git branch -u origin/serverfix Branch serverfix set up to track remote branch serverfix from origin.

Upstream shorthand

When you have a tracking branch set up, you can reference its upstream branch with the @ or @ shorthand. So if you’re on the master branch and it’s tracking origin/master , you can say something like git merge @ instead of git merge origin/master if you wish.

If you want to see what tracking branches you have set up, you can use the -vv option to git branch . This will list out your local branches with more information including what each branch is tracking and if your local branch is ahead, behind or both.

$ git branch -vv iss53 7e424c3 [origin/iss53: ahead 2] Add forgotten brackets master 1ae2a45 [origin/master] Deploy index fix * serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] This should do it testing 5ea463a Try something new

So here we can see that our iss53 branch is tracking origin/iss53 and is “ahead” by two, meaning that we have two commits locally that are not pushed to the server. We can also see that our master branch is tracking origin/master and is up to date. Next we can see that our serverfix branch is tracking the server-fix-good branch on our teamone server and is ahead by three and behind by one, meaning that there is one commit on the server we haven’t merged in yet and three commits locally that we haven’t pushed. Finally we can see that our testing branch is not tracking any remote branch.

It’s important to note that these numbers are only since the last time you fetched from each server. This command does not reach out to the servers, it’s telling you about what it has cached from these servers locally. If you want totally up to date ahead and behind numbers, you’ll need to fetch from all your remotes right before running this. You could do that like this:

$ git fetch --all; git branch -vv

Pulling

While the git fetch command will fetch all the changes on the server that you don’t have yet, it will not modify your working directory at all. It will simply get the data for you and let you merge it yourself. However, there is a command called git pull which is essentially a git fetch immediately followed by a git merge in most cases. If you have a tracking branch set up as demonstrated in the last section, either by explicitly setting it or by having it created for you by the clone or checkout commands, git pull will look up what server and branch your current branch is tracking, fetch from that server and then try to merge in that remote branch.

Generally it’s better to simply use the fetch and merge commands explicitly as the magic of git pull can often be confusing.

Deleting Remote Branches

Suppose you’re done with a remote branch — say you and your collaborators are finished with a feature and have merged it into your remote’s master branch (or whatever branch your stable codeline is in). You can delete a remote branch using the —delete option to git push . If you want to delete your serverfix branch from the server, you run the following:

$ git push origin --delete serverfix To https://github.com/schacon/simplegit - [deleted] serverfix

Basically all this does is to remove the pointer from the server. The Git server will generally keep the data there for a while until a garbage collection runs, so if it was accidentally deleted, it’s often easy to recover.

How can I tell a local branch to track a remote branch?

Understanding and making use of tracking relationships makes version control a whole lot easier. Let’s talk about both the concept and the practice of «tracking» branches.

The Git Cheat Sheet

No need to remember all those commands and parameters: get our popular «Git Cheat Sheet» — for free!

What are tracking connections in Git?

By default, branches in Git have nothing to do with each other. However, when you tell a local branch to «track» a remote branch, you create a connection between these two branches. Your local branch now has a «counterpart» on the remote server.

Why should you set up tracking connections?

Let’s say your current local HEAD branch is named «dev». And let’s also say that you have set it up to track the «dev» branch on the remote named «origin». This relationship is invaluable for two reasons:

1. Pushing and pulling becomes a lot easier. You can simply use the shorthand commands «git pull» and «git push» — instead of having to think about the exact parameters like in «git push origin dev». Even more importantly than being «easier», this also prevents you from making mistakes!
2. Git can now inform you about «unpushed» and «unpulled» commits. Let’s make an example:

(a) if you have 2 commits only locally that you haven’t pushed to the remote yet, your local branch is «2 commits ahead» of its remote counterpart branch.
(b) if, on the other hand, there are 4 commits on the remote branch that you haven’t downloaded yet, then your local branch is «4 commits behind» its remote counterpart branch.

This information helps tremendously in staying up-to-date. Git tells you about this right in the output for «git status»:

$ git status # On branch dev # Your branch and 'origin/dev' have diverged, # and have 1 and 2 different commits each, respectively. # nothing to commit (working directory clean) 

How do you track a remote branch?

There are three main scenarios for creating a tracking connection.

When you’re starting to work on an existing remote branch

Let’s say one of your colleagues has already started and published a branch on your remote server. You now want to chime in and start working on that topic, too. In that scenario, simply use the —track flag with the «git checkout» command:

$ git checkout --track origin/dev Branch dev set up to track remote branch dev from origin. Switched to a new branch 'dev' 

This creates a new local branch with the same name as the remote one — and directly establishes a tracking connection between the two.

When you’re publishing a local branch

Let’s now look at the opposite scenario: you started a new local branch and now want to publish it on the remote for the first time:

$ git push -u origin dev 

You can tell Git to track the newly created remote branch simply by using the -u flag with «git push».

When you decide at a later point in time

In cases when you simply forgot, you can set (or change) a tracking relationship for your current HEAD branch at any time:

$ git branch -u origin/dev 

Tip

Tracking Branches in Tower

In case you are using the Tower Git client, you’ll note that it uses tracking connections in many places to display helpful information:

Learn More

• Check out the chapter Inspecting Remote Data in our free online book
• More frequently asked questions about Git & version control

Get our popular Git Cheat Sheet for free!

You’ll find the most important commands on the front and helpful best practice tips on the back. Over 100,000 developers have downloaded it to make Git a little bit easier.

About Us

As the makers of Tower, the best Git client for Mac and Windows, we help over 100,000 users in companies like Apple, Google, Amazon, Twitter, and Ebay get the most out of Git.

Just like with Tower, our mission with this platform is to help people become better professionals.

That’s why we provide our guides, videos, and cheat sheets (about version control with Git and lots of other topics) for free.

© 2010-2023 Tower — Mentioned product names and logos are property of their respective owners.

Set as tracked branch что значит

Changes in the git-remote manual

1. 2.37.1 → 2.42.0 no changes
2. 2.37.0 06/27/22
3. 2.36.1 → 2.36.6 no changes
4. 2.36.0 04/18/22
5. 2.35.1 → 2.35.8 no changes
6. 2.35.0 01/24/22
7. 2.30.1 → 2.34.8 no changes
8. 2.30.0 12/27/20
9. 2.29.1 → 2.29.3 no changes
10. 2.29.0 10/19/20

Check your version of git by running

NAME

git-remote — Manage set of tracked repositories

SYNOPSIS

git remote [-v | --verbose] git remote add [-t ] [-m ] [-f] [--[no-]tags] [--mirror=(fetch|push)]  git remote rename [--[no-]progress]  git remote remove git remote set-head (-a | --auto | -d | --delete | ) git remote set-branches [--add] …​ git remote get-url [--push] [--all] git remote set-url [--push]  [] git remote set-url --add [--push]  git remote set-url --delete [--push]  git remote [-v | --verbose] show [-n] …​ git remote prune [-n | --dry-run] …​ git remote [-v | --verbose] update [-p | --prune] [( | )…​]

DESCRIPTION

Manage the set of repositories («remotes») whose branches you track.

OPTIONS

Be a little more verbose and show remote url after name. For promisor remotes, also show which filter ( blob:none etc.) are configured. NOTE: This must be placed between remote and subcommand.

COMMANDS

With no arguments, shows a list of existing remotes. Several subcommands are available to perform operations on the remotes.

Add a remote named for the repository at . The command git fetch can then be used to create and update remote-tracking branches /.

With -f option, git fetch is run immediately after the remote information is set up.

With —tags option, git fetch imports every tag from the remote repository.

With —no-tags option, git fetch does not import tags from the remote repository.

By default, only tags on fetched branches are imported (see git-fetch[1]).

With -t option, instead of the default glob refspec for the remote to track all branches under the refs/remotes// namespace, a refspec to track only is created. You can give more than one -t to track multiple branches without grabbing all branches.

With -m option, a symbolic-ref refs/remotes//HEAD is set up to point at remote’s branch. See also the set-head command.

When a fetch mirror is created with —mirror=fetch , the refs will not be stored in the refs/remotes/ namespace, but rather everything in refs/ on the remote will be directly mirrored into refs/ in the local repository. This option only makes sense in bare repositories, because a fetch would overwrite any local commits.

When a push mirror is created with —mirror=push , then git push will always behave as if —mirror was passed.

Rename the remote named to . All remote-tracking branches and configuration settings for the remote are updated.

In case and are the same, and is a file under $GIT_DIR/remotes or $GIT_DIR/branches , the remote is converted to the configuration file format.

Remove the remote named . All remote-tracking branches and configuration settings for the remote are removed.

Sets or deletes the default branch (i.e. the target of the symbolic-ref refs/remotes//HEAD ) for the named remote. Having a default branch for a remote is not required, but allows the name of the remote to be specified in lieu of a specific branch. For example, if the default branch for origin is set to master , then origin may be specified wherever you would normally specify origin/master .

With -d or —delete , the symbolic ref refs/remotes//HEAD is deleted.

With -a or —auto , the remote is queried to determine its HEAD , then the symbolic-ref refs/remotes//HEAD is set to the same branch. e.g., if the remote HEAD is pointed at next , git remote set-head origin -a will set the symbolic-ref refs/remotes/origin/HEAD to refs/remotes/origin/next . This will only work if refs/remotes/origin/next already exists; if not it must be fetched first.

Use to set the symbolic-ref refs/remotes//HEAD explicitly. e.g., git remote set-head origin master will set the symbolic-ref refs/remotes/origin/HEAD to refs/remotes/origin/master . This will only work if refs/remotes/origin/master already exists; if not it must be fetched first.

set-branches

Changes the list of branches tracked by the named remote. This can be used to track a subset of the available remote branches after the initial setup for a remote.

The named branches will be interpreted as if specified with the -t option on the git remote add command line.

With —add , instead of replacing the list of currently tracked branches, adds to that list.

Retrieves the URLs for a remote. Configurations for insteadOf and pushInsteadOf are expanded here. By default, only the first URL is listed.

With —push , push URLs are queried rather than fetch URLs.

With —all , all URLs for the remote will be listed.

Changes URLs for the remote. Sets first URL for remote that matches regex (first URL if no is given) to . If doesn’t match any URL, an error occurs and nothing is changed.

With —push , push URLs are manipulated instead of fetch URLs.

With —add , instead of changing existing URLs, new URL is added.

With —delete , instead of changing existing URLs, all URLs matching regex are deleted for remote . Trying to delete all non-push URLs is an error.

Note that the push URL and the fetch URL, even though they can be set differently, must still refer to the same place. What you pushed to the push URL should be what you would see if you immediately fetched from the fetch URL. If you are trying to fetch from one place (e.g. your upstream) and push to another (e.g. your publishing repository), use two separate remotes.

Gives some information about the remote .

With -n option, the remote heads are not queried first with git ls-remote ; cached information is used instead.

Deletes stale references associated with . By default, stale remote-tracking branches under are deleted, but depending on global configuration and the configuration of the remote we might even prune local tags that haven’t been pushed there. Equivalent to git fetch —prune , except that no new references will be fetched.

See the PRUNING section of git-fetch[1] for what it’ll prune depending on various configuration.

With —dry-run option, report what branches would be pruned, but do not actually prune them.

Fetch updates for remotes or remote groups in the repository as defined by remotes. . If neither group nor remote is specified on the command line, the configuration parameter remotes.default will be used; if remotes.default is not defined, all remotes which do not have the configuration parameter remote..skipDefaultUpdate set to true will be updated. (See git-config[1]).

With —prune option, run pruning against all the remotes that are updated.

DISCUSSION

The remote configuration is achieved using the remote.origin.url and remote.origin.fetch configuration variables. (See git-config[1]).

EXIT STATUS

On success, the exit status is 0 .

When subcommands such as add, rename, and remove can’t find the remote in question, the exit status is 2 . When the remote already exists, the exit status is 3 .

On any other error, the exit status may be any other non-zero value.

EXAMPLES

• Add a new remote, fetch, and check out a branch from it

$ git remote origin $ git branch -r origin/HEAD -> origin/master origin/master $ git remote add staging git://git.kernel.org/. /gregkh/staging.git $ git remote origin staging $ git fetch staging . From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging * [new branch] master -> staging/master * [new branch] staging-linus -> staging/staging-linus * [new branch] staging-next -> staging/staging-next $ git branch -r origin/HEAD -> origin/master origin/master staging/master staging/staging-linus staging/staging-next $ git switch -c staging staging/master .

$ mkdir project.git $ cd project.git $ git init $ git remote add -f -t master -m master origin git://example.com/git.git/ $ git merge origin