Git

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.

Important notes:

Remote Run and Pre-Tested Commit are supported in the IntelliJ IDEA plugin; with the Visual Studio Add-in, use the Branch Remote Run Trigger.
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.

Native Git for VCS-related operations on the server

TeamCity can now use native Git for VCS-related operations on the server. Using native Git improves the performance of the checking for changes operations on the server in comparison with the previously used JGit implementation. It also fixes a number of issues related to large Git repositories.

See known issues of the current native Git implementation in TeamCity.

General Settings

Fetch URL — the URL of the remote Git repository used for fetching data from the repository.
You can override the fetch URL for individual agents to allow them to use a closer proxy instead of the original VCS hosting. To do so, open a required agent's conf/buildAgent.properties file and add the redirection rule as follows: teamcity.git.fetchUrlMapping.<name> = <source URL> => <target URL>. For example:
snippet idPlain Text teamcity.git.fetchUrlMapping.firstrule = https://example.com/org/test.git => http://proxy.com/test.git
You can use partial addresses and the asterisk (`*`) wildcard to set up proxies for all fetch URLs that match the pattern. For example, the following rule allows an agent to use the `http://proxy.com/test/test.git` URL instead of the original `https://example.com/org/test/test.git`:
teamcity.git.fetchUrlMapping.secondrule = https://example.com/org/* => http://proxy.com/
Note that along with a fetch URL a VCS root also stores authentication settings required to access a repository. As such, replacing fetch URL is in effect only for VCS roots that use **Anonymous** or **Private key** authentication modes. Other modes do not guarantee an agent will be able to access a repository (for example, a refreshable token issued for a source VCS will not be accepted by a proxy hosting).
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 - the default branch. Parameter references are supported here. Default value is refs/heads/master.
You can configure Git-plugin to fetch all heads by adding the teamcity.git.fetchAllHeads=true custom parameter.
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).
Here, the pipe symbol | represents the OR command, as in regular expressions: use + for including, OR - for excluding.
Use tags as branches — allows monitoring / checking out git tags as branches making branch specification match tag names as well as branches (for example, +|-:refs/tags/<tag_name>). By default, tags are ignored.
Username style — 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.
Submodules — specifies whether submodule repositories should be checked out. For multi-level submodule setup, you can choose between the "Checkout" (recursively fetches the entire repository tree) and "Non-recursive checkout" (fetches only those submodules that are directly referenced by the main repository) modes. In the diagram below, submodules A and B are available in both modes, whereas submodules C and D require the recursive "Checkout" mode.
Main_Repo | |_________ Tier 1 Submodule A | | | |_________ Tier 2 Submodule C | |_________ Tier 1 Submodule B | |_________ Tier 2 Submodule D
Submodule repositories should either not require authentication or use the same protocol and accept the same authentication as configured in the VCS root. Otherwise, you need to configure additional credentials to access these repositories as described in the LFS and Submodules Support section.
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/* will match refs/heads/feature1 branch, but in the TeamCity interface you'll see only feature1 as 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://git.somwhere.org/repos/test.git, ssh://git@git.somwhereElse.org/repos/test.git, SCP-like syntax: git@git.somwhere.org:repos/test.git)

Git: (for example, git://git.kernel.org/pub/scm/git/git.git)
HTTP: (for example, http://git.somewhere.org/projects/test.git)
file: (for example, file:///c:/projects/myproject/.git)

Authentication Settings

Anonymous — select this option to clone a repository with anonymous read access.

Password / personal access token — specify a valid username (if there is no username in the clone URL, the username specified in this field 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.
You can use a personal access token instead of a password to authenticate in GitHub, Azure DevOps Services, GitLab, JetBrains Space, and Bitbucket. When connecting to Azure DevOps, remember to set the Code access scope to Code (read) / Code (read and write) for versioned settings in the repositories you are about to access from TeamCity.
Beginning August 13, 2021, GitHub will no longer accept passwords when authenticating Git operations on GitHub.com.
We highly recommend that you use an access token or SSH key instead of password when configuring a VCS root for a GitHub.com repository.
When using an existing Bitbucket Cloud, Bitbucket Server, GitLab or Azure DevOps Services connection to create a VCS Root, TeamCity will use a refreshable token instead of the password.

Refreshable token — if a VCS root that fetches data from a GitHub, GitHub App, Bitbucket Server, Bitbucket Cloud, Azure DevOps, GitLab, or JetBrains Space was configured using a TeamCity connection, refreshable tokens are enabled by default. Such tokens are short-lived providing more security than passwords or personal access tokens: the TeamCity server refreshes them automatically without sharing any related data with agents.
The Token field displays information about the user who obtained the token and the connection that provided the token.
You can specify a username here if there is no username in the clone URL (the username specified here overrides the username from the URL).
For Azure DevOps, GitHub App, Bitbucket Server, Bitbucket Cloud, JetBrains Space and GitLab connections you can click the Acquire new button to instantly reissue the token used by the VCS root with a token issued for the current user.
Private Key — valid only for SSH protocol. A private key must be in the OpenSSH format.
Recent versions of OpenSSH no longer generate keys in PEM format by default. The new OpenSSH format is not yet supported by TeamCity (see TW-53615). Use the following command to generate TeamCity-compatible keys: ssh-keygen -t rsa -m PEM.
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 — select this option to utilize the key(s) uploaded to the project.
- Default Private Key — select this option to utilize 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. Fill the Private Key Path field with an absolute path to the private key file on the server machine. If the key is encrypted, specify the passphrase in the corresponding field.

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, you can use both Azure DevOps OAuth and Azure DevOps PAT connections.

Server Settings

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

Option	Description
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.

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.

Option	Description
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.
Checkout policy	This setting defines how TeamCity performs a checkout to a build agent. Use mirrors: recommended for long-lived agents. With this option selected, TeamCity creates a remote repository cache on the agent machine under the `system/caches/git` directory. The cache is then added as alternates when updating the build checkout directory. To speed up the following checkouts of this repository, the agent will reuse the cache in all the builds with the same fetch URL. This also speeds up clean checkout (as only the build working directory is cleaned) and saves disk space (as the mirror is the only clone of the given repository on the agent). Do not use mirrors: choose to check out right into the build checkout directory, without creating a mirror. Less optimal in terms of disk usage than mirrors, but preserved for backwards compatibility with existing configurations. Shallow clone: recommended for short-lived agents; for example, for disposable cloud agents being terminated after every build. Creates a shallow clone by fetching only one required revision, which allows saving time on the build start. Choose this option only if you do not require a Git commit history in your builds and if your cloud image does not contain a fresh Git mirror. You can enforce this option on certain agents by specifying the `teamcity.git.shallowClone=true` agent configuration property. Auto: TeamCity will automatically apply one of the above approaches depending on the `teamcity.cloud.agent.terminate.after.build` agent configuration property and on the mirror presence on the agent.
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. 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, `git clean` will never delete these checkout directories during cleaning.

Option

Description

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.

Checkout policy

This setting defines how TeamCity performs a checkout to a build agent.

Use mirrors: recommended for long-lived agents. With this option selected, TeamCity creates a remote repository cache on the agent machine under the system/caches/git directory. The cache is then added as alternates when updating the build checkout directory. To speed up the following checkouts of this repository, the agent will reuse the cache in all the builds with the same fetch URL. This also speeds up clean checkout (as only the build working directory is cleaned) and saves disk space (as the mirror is the only clone of the given repository on the agent).
Do not use mirrors: choose to check out right into the build checkout directory, without creating a mirror. Less optimal in terms of disk usage than mirrors, but preserved for backwards compatibility with existing configurations.
Shallow clone: recommended for short-lived agents; for example, for disposable cloud agents being terminated after every build. Creates a shallow clone by fetching only one required revision, which allows saving time on the build start. Choose this option only if you do not require a Git commit history in your builds and if your cloud image does not contain a fresh Git mirror. You can enforce this option on certain agents by specifying the teamcity.git.shallowClone=true agent configuration property.
Auto: TeamCity will automatically apply one of the above approaches depending on the teamcity.cloud.agent.terminate.after.build agent configuration property and on the mirror presence on the agent.

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.

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, git clean will never delete these checkout directories during cleaning.

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:

for Windows — it tries to run git.exe at:
- C:\Program Files\Git\bin
- C:\Program Files (x86)\Git\bin
- C:\cygwin\bin
for *nix — it tries to run git at:
- /usr/local/bin
- /usr/bin
- /opt/local/bin
- /opt/bin

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.

LFS and Submodules Support

Common Information

Submodules and LFS are integral parts of many complex software products whose source code is stored in Git-based version control systems.

Submodules allow you to keep Git repositories as subdirectories of other Git repositories. For example, you may want to include a microservice developed by another team in your organization, or a 3rd-party open source project that your code relies on. As a result, you can clone a repository into your parent project while keeping commits separate.
Large File Storage (LFS) allows you to drastically reduce the size of your repository by moving bulky files (media files, databases, and so on) to an external storage, and replacing these files with pointers.

Although different in their scenarios and implementation mechanisms, both concepts suggest incorporating essential project components from external sources (a file hosted on a remote LFS server or another repository within a VCS). This means your TeamCity project needs to authenticate to different resources to check out source files.

Additional Credentials

If your repository imports submodules hosted on the same VCS and these imported repositories can be accessed via the same credentials stored in your VCS Root, you do not need to perform any additional modifications. TeamCity will check out all required source files using a single set of credentials.

Otherwise, if TeamCity needs to access an external LFS server or a different VCS that hosts required submodules, you will need to add three configuration parameters to your project:

teamcity.git.https.credentials.<ALIAS>.url = https://example.com/...
teamcity.git.https.credentials.<ALIAS>.username = johndoe
teamcity.git.https.credentials.<ALIAS>.password = 081ef11uh

<ALIAS> is a custom string that groups your teamcity.git.https.credentials... properties into sets of three, and is used to identify required properties. For example, if your GitHub repo should import bulky files from Sonatype Nexus LFS and additional submodules from Azure DevOps, you will need six properties. Three of them can have the nexus alias while the remaining have the azure alias. When TeamCity needs to access an Azure submodule repository, it will notice the URL is stored in an ...azure.url property and look for matching properties with the same alias: ...azure.username and ...azure.password.
URL is an HTTP(S) fetch URL for a submodule repo or an HTTP(S) link to an LFS storage. For example, https://github.com/username/submodule-repo-name.git or https://mynexus.com/repository/repo-name/info/lfs. SSH protocols are currently not supported.
Username and Password store credentials for the corresponding service. Note that all limitations and guidelines that are normally in effect for accessing regular repositories apply for LFS/submodule checkout as well. For example, the ...password property should store an access token instead of a regular account password since the latter option is being continuously discontinued by the majority of Git hostings. The ...username property should also store a value that can be used in conjunction with an access token (for example, a regular account name for GitHub and GitLab or "x-token-auth" for Bitbucket Cloud). See also:

Limitations and Tips

Configuration properties that store additional credentials should be configured for a TeamCity project, not a build configuration.
For security reasons, switch all ...password parameters to the password type. This will ensure your tokens and passwords are hidden from TeamCity UI, build logs, Kotlin DSL and REST API payloads. In addition, we recommend enabling the Read-only setting for teamcity.git.https.credentials.<ALIAS>.url parameters to prevent potential attackers from writing their own handcrafted URL to this parameter and stealing your authorization tokens.
We recommend using Git LFS version 2.12.1 or later as earlier versions come with a vulnerability exploit.
TeamCity supports Git LFS only for the agent-side checkout.
Accessing submodule repositories and LFS files is currently supported only via secure HTTPS protocol. SSH and HTTP protocols are not supported.

Agent-side checkout rules limitations

The Git plugin uses git sparse-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:

+:dirA/dirA1
-:dirA/dirA1/dirA2

+:. => dirA/dirA1/dirA2

+:dirA => dirA

+:dirA/dirA1 => dirA/dirA1

+:dirA/dirB/dirC => dirD/dirE/dirA/dirB/dirC

Note that rules must not remap files. That is, the following rule is not supported: +:dirA/dirA1 => dirA/dirA2.

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 ([prefix/]). Only the rules +:dirA => [prefix/]dirA are supported for agent-side checkout, and the [prefix/] must be the same for all rules.

For example:

+:dirA/dirB/dirC => [prefix/]dirA/dirB/dirC
+:dirD/dirE/dirF => [prefix/]dirD/dirE/dirF

Note that the following rule is not supported: +:dirA=>[prefix/]dirA/postfix. If you append [/postfix] to the checkout directory path and the configuration's VCS checkout mode is set to "Always checkout files on agent", new builds will be unable to start.

Last modified: 18 September 2024