TeamCity supports Git out of the box. Git source control with Azure DevOps 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.
Initial Git checkout may take significant time (sometimes hours), depending on the size of your project history, because the whole project history is downloaded during the initial checkout.
The URL of the remote Git repository used for fetching data from the repository.
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.
Configures default branch. Parameter references are supported here. Default value is
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:
Use tags as branches
Allows monitoring / checking out git tags as branches making branch specification match tag names as well as branches (for example,
Defines a way TeamCity reports username for a VCS change. 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
If the branch matches a line without patterns, the line is used.
If the branch matches several lines with patterns, the best matching line is used.
If there are several lines with equal matching, the one below takes precedence.
Everything that is matched by the wildcard will be shown as a branch name in the TeamCity interface. For example,
refs/heads/feature1branch, but in the TeamCity interface you'll see only
feature1as a branch name.
The short name of the branch is determined as follows:
if the line contains no brackets, then full line is used, if there are no patterns or part of line starting with the first pattern-matched character to the last pattern-matched character.
if the line contains brackets, then part of the line within brackets is used. When branches are specified here, and if your build configuration has a VCS trigger and a change is found in some branch, TeamCity will trigger a build in this branch.
Supported Git Protocols
The following protocols are supported for Git repository URL:
ssh: (for example,
ssh://firstname.lastname@example.orgElse.org/repos/test.git, SCP-like syntax:
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.
You can use a personal access token instead of a password to authenticate in GitHub, Azure DevOps Services, GitLab, and Bitbucket.
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).
For all available options to connect to GitHub, see the comment.
Authenticating to Azure DevOps Services
If you use Git source control with Azure DevOps Services, the following options are available to you:
Personal Access Tokens
To use access tokens, you need to create a personal access token in your Azure DevOps account, where you have to set some Code access scope in your repositories and use it when configuring a VCS root.
Leave blank for TFVC, any value for Git, for example, username
Enter your personal access token created earlier
Required Access Scope
Code (read) / Code (read and write) for versioned settings
Work items (read)
Alternate Authentication Credentials
To use the login/password pair authentication, you have to enable alternate credentials in your Azure DevOps account, where you can set a secondary username and password to use when configuring a VCS root.
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
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
Clean Policy/Clean Files Policy
Specify here when the
If a build configuration depends on multiple VCS roots, we suggest that you configure separate agent checkout directories for each of these roots, using VCS checkout rules. This way,
It is recommended to always leave this option enabled.
When enabled (default), TeamCity clones the Git repository and creates its mirror under the agent's
See also, how to prepare a mirror on a cloud agent.
If you disable this option, TeamCity will clone the repository directly under the build's working directory, unless the
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
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.
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:
- for Windows - it tries to run
C:\Program Files (x86)\Git\bin
- for *nix - it tries to run
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.
Git mirrors on cloud agents
By default, TeamCity creates a mirror, that is a copy, of your Git repository under the agent's
system/git directory. To save time and disk space on fetching source files, TeamCity points to this mirror via the Git alternate mechanism when updating the checkout directory for a build.
Comparing to self-hosted TeamCity agents, cloud agents require extra steps to add a Git mirror:
When preparing a cloud image, clone the repository under the agent image's
system/gitdirectory. If necessary, you can store multiple
*.gitdirectories side by side.
mapfile under the
system/gitdirectory and describe the mapping between the original repository and its mirror. For example,ssh://git@<host>/<git_folder>.git = <git_folder>.git
When starting a build, a cloud agent will check the mirrors specified in the
map file and fetch the difference between the required origin and its mirror. The origin URL in the
map file must match the URL set in the VCS root.
This way, builds will run significantly faster, with no need to check out the whole remote repository every time the new cloud agent starts.
Configuring Git Garbage Collection on Server
TeamCity server maintains a local clone for every Git repository used in the VCS roots configured on the server. Since the server performs fetch in those clones many times a day, the clone needs regular optimization to maintain predictable performance. If the Git garbage collection for the clone was not run for a long time, the process of collecting changes may slow down or start to report memory-related errors. TeamCity can automatically run git gc periodically when native Git client can be found on the server. Inability to run Git GC results in a related health report.
To fix the warning / meet automatic git gc requirements, perform the following:
Install a native Git client manually on the TeamCity server.
- Specify the path to the Git executable:
Add the directory with the executable to the
PATHenvironment variable and restart the server, or
Set the full path to the executable in the
teamcity.server.git.executable.pathinternal property without the server restart.
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.
TeamCity executes Git garbage collection until the total time doesn't exceed 5 hours 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 * * ?. If the
git gc process works slowly and cannot be completed in the allotted time, check the
git-repack configuration in the default Git configuration files (for example, you can increase
--window-memory to improve the
git gc performance).
If the local Git clones need some kind of manual maintenance, you can find them under
<TeamCity Data Directory>/system/caches/git directory. The
map file in the directory contains mapping between the repository URL and the subdirectory storing the bare clone of the repository.
TeamCity supports Git LFS for agent-side checkout. To use it, install git 1.8.+ 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 the Git LFS documentation.
We recommend using Git LFS version 2.12.1 or later as earlier versions come with a vulnerability exploit.
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
Defines whether TeamCity runs
This property provides the explicit
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
By default, TeamCity starts nested Java processes for
This property specifies the maximum possible
Whether TeamCity should run
The path to the native git executable on the server
Maximum amount of time to run
0 0 2 * * ? *
Cron expression for the time of a clean-up in git-plugin, by default – daily at 2AM.
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:
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
_TeamCity checks the state of this property only if the "Use mirrors" option is disabled in the VCS root settings. _
By default, if you disable "Use mirrors", TeamCity will clone the repository under the build's working directory.
Build parameters for Git:
When checkout on agent: whether TeamCity should use native SSH implementation.
The idle timeout for the
The Git plugin uses
git sparce-checkout to check out Git files on an agent. The plugin is able to perform only simple file mapping operations which limits the set of supported VCS checkout rules for Git.
The following rules are supported:
If you specify multiple checkout rules for one root, make sure their checkout directories (the right part of the rule) have a common parent directory. For example:
java.lang.OutOfMemoryErrorwhile fetching from a repository in case
teamcity.git.fetch.process.max.memoryproperty is specified. Since TeamCity 2019.2, the recommended approach is to disable this property thus delegating the automatic memory management to TeamCity.
Teamcity running as a Windows service cannot access a network mapped drives, so you cannot work with git repositories located on such drives. To make this work, run TeamCity using
Inflation using streams in JGit prevents
OutOfMemoryError, but can be time-consuming (see the related thread at jgit-dev for details and the TW-14947 issue related to the problem). If you meet conditions similar to those described in the issue, try to increase
teamcity.git.stream.file.threshold.mb. Additionally, it is recommended to increase the overall amount of memory dedicated for TeamCity to prevent
Git support is implemented as an open-source plugin. For development links, refer to the plugin's page.