{alias:Git (JetBrains)}
TeamCity supports Git out of the box. Git source control with Visual Studio Team Services is supported (see authentication notes below).

This page contains description of the Git-specific fields of the VCS root settings.
For common VCS Root properties, see this section.

Git command line client needs to be installed on the agents if the agent-side checkout is used.

On this page:


General Settings



Fetch URL

The URL of the remote Git repository used for fetching data from the repository.

Push URL

The URL of the target remote Git repository used for pushing annotated tags created via VCS labeling build feature to the remote repository. If blank, the fetch URL is used.

Default branch

Configures default branch. Parameter references are supported here. Default value is refs/heads/master

You can configure Git-plugin to fetch all heads by adding a build configuration parameter teamcity.git.fetchAllHeads=true

Branch specification

Lists the patterns for branch names, required for feature branches support. The matched branches are monitored for changes in addition to the default branch. The syntax is similar to checkout rules: +|-:branch_name, where branch_name is specific to the VCS, i.e. refs/heads/ in Git (with the optional * placeholder).

Use tags as branches

Allows monitoring / checking out git tags as branches making branch specification match tag names as well as branches (e.g. +|-:refs/tags/<tag_name>). By default, tags are ignored.

Username style

Defines a way TeamCity reports username for a VCS change. The username is reported based on the Author field of the Git commit and can include name, email or their combinations.
Changing the username style will affect only newly collected changes. Old changes will continue to be stored with the style that was active at the time of collecting changes.


Select whether you want to ignore the submodules, or treat them as a part of the source tree. Submodule repositories should either not require authentication or use the same protocol and accept the same authentication as configured in the VCS root.

Username for tags/merge

A custom username used for labeling.

Branch Matching Rules

Supported Git Protocols

The following protocols are supported for Git repository URL:

Authentication Settings

Authentication Method



Select this option to clone a repository with anonymous read access.


Specify a valid username (if there is no username in the clone URL; the username specified here overrides the username from the URL) and a password to be used to clone the repository.
For the agent-side checkout, it is supported only if git 1.7.3+ client is installed on the agent. See TW-18711.
For Git hosted from Team Foundation Server 2013, specify NTLM credentials here.

Private Key

Valid only for SSH protocol. A private key must be in the OpenSSH format. Select one of the options from the Private Key list and specify a valid username (if there is no username in the clone URL; the username specified here overrides the username from the URL).
Available Private Key options:

  • Uploaded Key: uses the key(s) uploaded to the project. See SSH Keys Management for details.
  • Default Private key - Uses the keys available on the file system in the default locations used by common ssh tools: the mapping specified in <USER_HOME>/.ssh/config if the file exists or the private key file <USER_HOME>/.ssh/id_rsa (the files are required to be present on the server and also on the agent if the agent-side checkout is used).
  • Custom Private Key - Supported only for server-side checkout, see TW-18449. When this method is used, specify an absolute path to the private key in the Private Key Path field. If required, specify the passphrase to access your SSH key in the corresponding field.

For all the available options to connect to GitHub, please see the comment.

Authenticating to Visual Studio Team Services
Applications that work outside the browser, such as the git client or the command-line TFS client, require basic authentication credentials to work. When configuring a VCS Root for a project hosted on Visual Studio Team Services, enable alternate credentials support in your Visual Studio Team Services account.

Authenticating to Visual Studio Team Services

If you use Git source control with Visual Studio Team Services, the following options are available to you:

Server Settings

These are the settings used in case of the server-side checkout.



Convert line-endings to CRLF

Convert line-endings of all text files to CRLF (works as setting core.autocrlf=true in a repository config). When not selected, no line-endings conversion is performed (works as setting core.autocrlf=false). Affects the server-side checkout only. A change to this property causes a clean checkout.

Custom clone directory on server

To interact with the remote git repository, the its bare clone is created on the TeamCity server machine. By default, the cloned repository is placed under <TeamCity Data Directory>/system/caches/git and <TeamCity Data Directory>/system/caches/git/map. The field specifies the mapping between repository url and its directory on the TeamCity server. Leave this field blank to use the default location.

Agent Settings

These are the settings used in case of the agent-side checkout.
Note that the agent-side checkout has limited support for SSH. The only supported authentication methods are "Default Private Key" and "Uploaded Private Key" .
If you plan to use the agent-side checkout, you need to have Git 1.6.4+ installed on the agents.



Path to git

Provide the path to a git executable to be used on the agent. When set to %env.TEAMCITY_GIT_PATH%, the automatically detected git will be used, see Git executable on the agent for details

Clean Policy/Clean Files Policy

Specify here when the "git clean" command is to run on the agent, and which files are to be removed.

Use mirrors

When enabled (default), TeamCity clones the repository under the agent's system\git directory and uses the mirror as an alternate repository when updating the checkout directory for the build. As a result, this speeds-up clean checkout (because only the working directory is cleaned), and saves disk space (as there is only one clone of the given git repository on an agent).

To configure a connection from a TeamCity server running behind a proxy to a remote Git repository, see this section.



Git executable on the agent

TeamCity needs Git command line client version 1.6.4+ on the agent in order to use the agent-side checkout.

The recommended approach is to ensure that the git client is available in PATH of the TeamCity agent and leave the "Path to git" setting in the VCS root blank.
If you only have the git command line on some machines, set "Path to git" setting in the VCS root to the %env.TEAMCITY_GIT_PATH% value.

Instead of adding Git to the agent's PATH, you can set the TEAMCITY_GIT_PATH environment variable (or env.TEAMCITY_GIT_PATH property in the agent's buildAgent.properties file) to the full path to the git executable.

If TEAMCITY_GIT_PATH is not defined, the Git agent plugin tries to detect the installed git on the launch of the agent. It first tries to run git from the following locations:

If git is not found in any of these locations, it tries to run the git accessible via the PATH environment variable.
If a compatible git (1.6.4+) is found, it is reported in the TEAMCITY_GIT_PATH environment variable. This variable can be used in the Path to git field in the VCS root settings. As a result, the configuration with such a VCS root will run only on the agents where git was detected or specified in the agent properties.

Configuring Git Garbage Collection on Server

TeamCity server maintains a clone for every Git repository it works with, so the process which collects changes in the large Git repository may cause memory problems on the TeamCity server if the Git garbage collection for the repository was not run for a long time.
TeamCity can automatically run git gc periodically when native Git client can be found on the server.

When TeamCity runs Git garbage collection, the details are logged into the teamcity-cleanup.log. If git garbage collection fails, a corresponding warning is displayed. To fix the warning / meet automatic git gc requirements, perform the following:

  1. Install a native Git client manually on the TeamCity server.
  2. Specify the directory to the Git executable:
    1. either add it to  the Path environment variable and restart the server,
    2. or set it in the  teamcity.server.git.executable.path internal property without the server restart.

TeamCity executes Git garbage collection until the total time doesn't exceed 60 minutes quota; the quota can be changed using the teamcity.server.git.gc.quota.minutes internal property.
Git garbage collection is executed every night at 2 a.m., this can be changed by specifying the internal property with a cron expression like this: "teamcity.git.cleanupCron=0 0 2 * * ?" (restart the server for the property to take effect)

If git gc process is slow and cannot be finished within allotted time, check git-repack configuration in the default git configuration files. e.g. "--window-memory" can be increased to improve git gc performance.

When Git gc is configured, TeamCity will run automatically in the background it for all currently monitored VCS roots.
With large Git repositories, if git gc has not been performed for a long time, garbage collection may take significant time.
Alternatively, you can stop TeamCity and delete the entire content of <TeamCity Data Directory>/system/caches/git directory to force fresh clones. If you do not want to do a fresh clone, you can stop TeamCity and run "git gc" manually for all the <git-XXX> git clones in the directory.


TeamCity supports Git LFS for agent-side checkout. To use it, install git 1.8.5+ and Git LFS on the build agent machine. Git LFS should be enabled using the 'git lfs install' command (on Windows an elevated command prompt may be needed). More information is available in Git LFS documentation

Internal Properties

For Git VCS it is possible to configure the following internal properties:






The idle timeout for communication with the remote repository. If no data were sent or received during this timeout, the plugin throws a timeout error to prevent hanging of the process forever.



(deprecated) Override of "teamcity.git.idle.timeout.seconds" for git fetch operation



Defines whether TeamCity runs git fetch in a separate process



The value of the JVM -Xmx parameter for a separate fetch process. You also need to ensure the server machine has enough memory as the memory configured will be used in addition to the main server process and there can be several child processes doing git fetch and each using the configured amount of the memory.

For large repositories requiring heap memory greater than -Xmx1024m for Git fetch, switching to 64-bit Java may be needed.

auto configure issue: https://youtrack.jetbrains.com/issue/TW-24666






Whether TeamCity should run git gc during the server cleanup (native git is used)



The path to the native git executable on the server



Maximum amount of time to run git gc


0 0 2 * * ? *

Cron expression for the time of a cleanup in git-plugin, by default - daily at 2a.m.



Threshold in megabytes after which JGit uses streams to inflate objects. Increase it if you have large binary files in the repository and see symptoms described in TW-14947



Git-plugin builds patches in a separate process, set it to false to build patch in the server process. To build patch git-plugin has to read repository files into memory. To not run out of memory git-plugin reads only objects of size smaller than the threshold, for larger objects streams are used and they can be slow (TW-14947). With patch building in a separate process all objects are read into memory. Patch process uses the memory settings of the separate fetch process.



The number of days after which an unused clone of the repository will be removed from the server machine. The repository is considered unused if there were no TeamCity operations on this repository, like checking for changes or getting the current version. These operations are quite frequent, so 7 days is a reasonably high value.



Defines whether to log additional debug info on each found commit



Type of ssh proxy, supported values: http, socks4, socks5. Please keep in mind that socks4 proxy cannot resolve remote host names, so if you get an UnknownHostException, either switch to socks5 or add an entry for your git server into the hosts file on the TeamCity server machine.



Ssh proxy host



Ssh proxy port



Number of attempts to establish connection to the remote host for testing connection and getting a current repository state before admitting a failure



Interval in seconds between connection attempts

Agent configuration for Git:






When checkout on agent: whether TeamCity should use native SSH implementation.

| teamcity.git.use.local.mirrors         | false   | When checkout on agent: whether TeamCity should clone to the local agent a mirror first and then clone to the working directory from this local mirror. This option speed-ups clean checkout, because only the build working directory is cleaned. Also if a single root is used in several build configurations, cloning will be faster. |
| teamcity.git.useAlternates             | false   | Alternates work like mirrors, but instead of cloning from a mirror to a working directory TeamCity uses a mirror as an alternate repository . As a result there is only one clone of the given git repository on an agent. This property can be set either in the agent properties or as a parameter in the build configuration. || teamcity.git.use.shallow.clone         | false   | When checkout on agent: run fetch with the option '--depth=1' if the agent uses local mirrors. This property can be set either in the agent properties or as a parameter in the build configuration. |{hidden-data}



The idle timeout for the git fetch operation when the agent-side checkout is used. The fetch is terminated if there is no output from the fetch process during this time. Prior to 8.0.4 the default was 600.


When using checkout on an agent, a limited subset of checkout rules is supported. Git-plugin translates some of the checkout rules to the sparse checkout patterns. Only the rules which do not remap files are supported:


An unsupported rule example is  +:some/dir=>some/otherDir.

Known Issues

Development Links

Git support is implemented as an open-source plugin. For development links, refer to the plugin's page.

See also:

Administrator's Guide: Branch Remote Run Trigger