docs/versions/9.3.0/rules/lib/repo/git.mdx

---
title: 'git repository rules'
---


The following functions can be loaded from
`@bazel_tools//tools/build_defs/repo:git.bzl`.


Rules for cloning external git repositories.

<a id="git_repository"></a>

## git_repository

```
load("@bazel//tools/build_defs/repo:git.bzl", "git_repository")

git_repository(<a href="#git_repository-name">name</a>, <a href="#git_repository-branch">branch</a>, <a href="#git_repository-build_file">build_file</a>, <a href="#git_repository-build_file_content">build_file_content</a>, <a href="#git_repository-canonical_id">canonical_id</a>, <a href="#git_repository-commit">commit</a>, <a href="#git_repository-init_submodules">init_submodules</a>,
               <a href="#git_repository-patch_args">patch_args</a>, <a href="#git_repository-patch_cmds">patch_cmds</a>, <a href="#git_repository-patch_cmds_win">patch_cmds_win</a>, <a href="#git_repository-patch_strip">patch_strip</a>, <a href="#git_repository-patch_tool">patch_tool</a>, <a href="#git_repository-patches">patches</a>,
               <a href="#git_repository-recursive_init_submodules">recursive_init_submodules</a>, <a href="#git_repository-remote">remote</a>, <a href="#git_repository-remote_module_file_integrity">remote_module_file_integrity</a>,
               <a href="#git_repository-remote_module_file_urls">remote_module_file_urls</a>, <a href="#git_repository-remote_patch_strip">remote_patch_strip</a>, <a href="#git_repository-remote_patches">remote_patches</a>, <a href="#git_repository-shallow_since">shallow_since</a>,
               <a href="#git_repository-sparse_checkout_file">sparse_checkout_file</a>, <a href="#git_repository-sparse_checkout_patterns">sparse_checkout_patterns</a>, <a href="#git_repository-strip_prefix">strip_prefix</a>, <a href="#git_repository-tag">tag</a>, <a href="#git_repository-verbose">verbose</a>,
               <a href="#git_repository-workspace_file">workspace_file</a>, <a href="#git_repository-workspace_file_content">workspace_file_content</a>)
```

Clone an external git repository.

Clones a Git repository, checks out the specified branch, tag, or commit, and
makes its targets available for binding. If no branch, tag or commit is
specified, check out the repository's default branch. Also determine the id
and date of the commit that was checked out, and return a dict with
parameters that provide a reproducible version of this rule (which a tag or
branch not necessarily is).

Bazel will first try to perform a shallow fetch of only the specified commit.
If that fails (usually due to missing server support), it will fall back to a
full fetch of the repository.

Prefer [`http_archive`](/versions/9.3.0/rules/lib/repo/http#http_archive) to `git_repository`.
The reasons are:

* Git repository rules depend on system `git(1)` whereas the HTTP downloader is built
  into Bazel and has no system dependencies.
* `http_archive` supports a list of `urls` as mirrors, and `git_repository` supports only
  a single `remote`.
* `http_archive` works with the [repository cache](/versions/9.3.0/run/build#repository-cache), but not
  `git_repository`. See
   [#5116](https://github.com/bazelbuild/bazel/issues/5116) for more information.

**ATTRIBUTES**

<table class="params-table">
<colgroup>
<col class="col-param" />
<col class="col-description" />
</colgroup>
<tbody>
<tr id="git_repository-name">
<td><code>name</code></td>
<td>
<a href="https://bazel.build/versions/9.3.0/concepts/labels#target-names">Name</a>; required

<p>

A unique name for this repository.

</p>
</td>
</tr>
<tr id="git_repository-branch">
<td><code>branch</code></td>
<td>
String; optional

<p>

branch in the remote repository to checked out. Precisely one of branch, tag, or commit must be specified.

</p>
</td>
</tr>
<tr id="git_repository-build_file">
<td><code>build_file</code></td>
<td>
<a href="https://bazel.build/versions/9.3.0/concepts/labels">Label</a>; optional

<p>

The file to use as the BUILD file for this repository. This attribute is an absolute label (use '@//' for the main repo). The file does not need to be named BUILD, but can be (something like BUILD.new-repo-name may work well for distinguishing it from the repository's actual BUILD files).

</p>
</td>
</tr>
<tr id="git_repository-build_file_content">
<td><code>build_file_content</code></td>
<td>
String; optional

<p>

The content for the BUILD file for this repository.

</p>
</td>
</tr>
<tr id="git_repository-canonical_id">
<td><code>canonical_id</code></td>
<td>
String; optional

<p>

A canonical ID of the file downloaded.

If specified and non-empty, Bazel will not take the file from cache, unless it
was added to the cache by a request with the same canonical ID.

If unspecified or empty, Bazel by default uses the URLs of the file as the
canonical ID. This helps catch the common mistake of updating the URLs without
also updating the hash, resulting in builds that succeed locally but fail on
machines without the file in the cache. This behavior can be disabled with
--repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0.

</p>
</td>
</tr>
<tr id="git_repository-commit">
<td><code>commit</code></td>
<td>
String; optional

<p>

specific commit to be checked out. Precisely one of branch, tag, or commit must be specified.

</p>
</td>
</tr>
<tr id="git_repository-init_submodules">
<td><code>init_submodules</code></td>
<td>
Boolean; optional

<p>

Whether to clone submodules in the repository.

</p>
</td>
</tr>
<tr id="git_repository-patch_args">
<td><code>patch_args</code></td>
<td>
List of strings; optional

<p>

The arguments given to the patch tool. Defaults to -p0 (see the `patch_strip` attribute), however -p1 will usually be needed for patches generated by git. If multiple -p arguments are specified, the last one will take effect.If arguments other than -p are specified, Bazel will fall back to use patch command line tool instead of the Bazel-native patch implementation. When falling back to patch command line tool and patch_tool attribute is not specified, `patch` will be used.

</p>
</td>
</tr>
<tr id="git_repository-patch_cmds">
<td><code>patch_cmds</code></td>
<td>
List of strings; optional

<p>

Sequence of Bash commands to be applied on Linux/Macos after patches are applied.

</p>
</td>
</tr>
<tr id="git_repository-patch_cmds_win">
<td><code>patch_cmds_win</code></td>
<td>
List of strings; optional

<p>

Sequence of Powershell commands to be applied on Windows after patches are applied. If this attribute is not set, patch_cmds will be executed on Windows, which requires Bash binary to exist.

</p>
</td>
</tr>
<tr id="git_repository-patch_strip">
<td><code>patch_strip</code></td>
<td>
Integer; optional

<p>

When set to `N`, this is equivalent to inserting `-pN` to the beginning of `patch_args`.

</p>
</td>
</tr>
<tr id="git_repository-patch_tool">
<td><code>patch_tool</code></td>
<td>
String; optional

<p>

The patch(1) utility to use. If this is specified, Bazel will use the specified patch tool instead of the Bazel-native patch implementation.

</p>
</td>
</tr>
<tr id="git_repository-patches">
<td><code>patches</code></td>
<td>
<a href="https://bazel.build/versions/9.3.0/concepts/labels">List of labels</a>; optional

<p>

A list of files that are to be applied as patches after extracting the archive. By default, it uses the Bazel-native patch implementation which doesn't support binary patch, but Bazel will fall back to use patch command line tool if `patch_tool` attribute is specified or there are arguments other than `-p` in `patch_args` attribute.

</p>
</td>
</tr>
<tr id="git_repository-recursive_init_submodules">
<td><code>recursive_init_submodules</code></td>
<td>
Boolean; optional

<p>

Whether to clone submodules recursively in the repository.

</p>
</td>
</tr>
<tr id="git_repository-remote">
<td><code>remote</code></td>
<td>
String; required

<p>

The URI of the remote Git repository

</p>
</td>
</tr>
<tr id="git_repository-remote_module_file_integrity">
<td><code>remote_module_file_integrity</code></td>
<td>
String; optional

<p>

For internal use only.

</p>
</td>
</tr>
<tr id="git_repository-remote_module_file_urls">
<td><code>remote_module_file_urls</code></td>
<td>
List of strings; optional

<p>

For internal use only.

</p>
</td>
</tr>
<tr id="git_repository-remote_patch_strip">
<td><code>remote_patch_strip</code></td>
<td>
Integer; optional

<p>

The number of leading slashes to be stripped from the file name in the remote patches.

</p>
</td>
</tr>
<tr id="git_repository-remote_patches">
<td><code>remote_patches</code></td>
<td>
<a href="https://bazel.build/versions/9.3.0/rules/lib/dict">Dictionary: String -> String</a>; optional

<p>

A map of patch file URL to its integrity value, they are applied after cloning the repository and before applying patch files from the `patches` attribute. It uses the Bazel-native patch implementation, you can specify the patch strip number with `remote_patch_strip`

</p>
</td>
</tr>
<tr id="git_repository-shallow_since">
<td><code>shallow_since</code></td>
<td>
String; optional

<p>

an optional date, not after the specified commit; the argument is not allowed if a tag or branch is specified (which can always be cloned with --depth=1). Setting such a date close to the specified commit may allow for a shallow clone of the repository even if the server does not support shallow fetches of arbitrary commits. Due to bugs in git's --shallow-since implementation, using this attribute is not recommended as it may result in fetch failures.

</p>
</td>
</tr>
<tr id="git_repository-sparse_checkout_file">
<td><code>sparse_checkout_file</code></td>
<td>
<a href="https://bazel.build/versions/9.3.0/concepts/labels">Label</a>; optional

<p>

File containing .gitignore-style patterns for a sparse checkout of files in this repository. Either `sparse_checkout_patterns` or `sparse_checkout_file` may be specified, or neither, but not both.

</p>
</td>
</tr>
<tr id="git_repository-sparse_checkout_patterns">
<td><code>sparse_checkout_patterns</code></td>
<td>
List of strings; optional

<p>

Sequence of patterns for a sparse checkout of files in this repository.

</p>
</td>
</tr>
<tr id="git_repository-strip_prefix">
<td><code>strip_prefix</code></td>
<td>
String; optional

<p>

A directory prefix to strip from the extracted files.

</p>
</td>
</tr>
<tr id="git_repository-tag">
<td><code>tag</code></td>
<td>
String; optional

<p>

tag in the remote repository to checked out. Precisely one of branch, tag, or commit must be specified.

</p>
</td>
</tr>
<tr id="git_repository-verbose">
<td><code>verbose</code></td>
<td>
Boolean; optional
</td>
</tr>
<tr id="git_repository-workspace_file">
<td><code>workspace_file</code></td>
<td>
<a href="https://bazel.build/versions/9.3.0/concepts/labels">Label</a>; optional

<p>

No-op attribute; do not use.

</p>
</td>
</tr>
<tr id="git_repository-workspace_file_content">
<td><code>workspace_file_content</code></td>
<td>
String; optional

<p>

No-op attribute; do not use.

</p>
</td>
</tr>
</tbody>
</table>

**ENVIRONMENT VARIABLES**

This repository rule depends on the following environment variables:

* `BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID`


<a id="new_git_repository"></a>

## new_git_repository

```
load("@bazel//tools/build_defs/repo:git.bzl", "new_git_repository")

new_git_repository(<a href="#new_git_repository-name">name</a>, <a href="#new_git_repository-branch">branch</a>, <a href="#new_git_repository-build_file">build_file</a>, <a href="#new_git_repository-build_file_content">build_file_content</a>, <a href="#new_git_repository-canonical_id">canonical_id</a>, <a href="#new_git_repository-commit">commit</a>,
                   <a href="#new_git_repository-init_submodules">init_submodules</a>, <a href="#new_git_repository-patch_args">patch_args</a>, <a href="#new_git_repository-patch_cmds">patch_cmds</a>, <a href="#new_git_repository-patch_cmds_win">patch_cmds_win</a>, <a href="#new_git_repository-patch_strip">patch_strip</a>, <a href="#new_git_repository-patch_tool">patch_tool</a>,
                   <a href="#new_git_repository-patches">patches</a>, <a href="#new_git_repository-recursive_init_submodules">recursive_init_submodules</a>, <a href="#new_git_repository-remote">remote</a>, <a href="#new_git_repository-remote_module_file_integrity">remote_module_file_integrity</a>,
                   <a href="#new_git_repository-remote_module_file_urls">remote_module_file_urls</a>, <a href="#new_git_repository-remote_patch_strip">remote_patch_strip</a>, <a href="#new_git_repository-remote_patches">remote_patches</a>, <a href="#new_git_repository-shallow_since">shallow_since</a>,
                   <a href="#new_git_repository-sparse_checkout_file">sparse_checkout_file</a>, <a href="#new_git_repository-sparse_checkout_patterns">sparse_checkout_patterns</a>, <a href="#new_git_repository-strip_prefix">strip_prefix</a>, <a href="#new_git_repository-tag">tag</a>, <a href="#new_git_repository-verbose">verbose</a>,
                   <a href="#new_git_repository-workspace_file">workspace_file</a>, <a href="#new_git_repository-workspace_file_content">workspace_file_content</a>)
```

Clone an external git repository.

Clones a Git repository, checks out the specified branch, tag, or commit, and
makes its targets available for binding. If no branch, tag or commit is
specified, check out the repository's default branch. Also determine the id
and date of the commit that was checked out, and return a dict with
parameters that provide a reproducible version of this rule (which a tag or
branch not necessarily is).

Bazel will first try to perform a shallow fetch of only the specified commit.
If that fails (usually due to missing server support), it will fall back to a
full fetch of the repository.

Prefer [`http_archive`](/versions/9.3.0/rules/lib/repo/http#http_archive) to `git_repository`.
The reasons are:

* Git repository rules depend on system `git(1)` whereas the HTTP downloader is built
  into Bazel and has no system dependencies.
* `http_archive` supports a list of `urls` as mirrors, and `git_repository` supports only
  a single `remote`.
* `http_archive` works with the [repository cache](/versions/9.3.0/run/build#repository-cache), but not
  `git_repository`. See
   [#5116](https://github.com/bazelbuild/bazel/issues/5116) for more information.

**ATTRIBUTES**

<table class="params-table">
<colgroup>
<col class="col-param" />
<col class="col-description" />
</colgroup>
<tbody>
<tr id="new_git_repository-name">
<td><code>name</code></td>
<td>
<a href="https://bazel.build/versions/9.3.0/concepts/labels#target-names">Name</a>; required

<p>

A unique name for this repository.

</p>
</td>
</tr>
<tr id="new_git_repository-branch">
<td><code>branch</code></td>
<td>
String; optional

<p>

branch in the remote repository to checked out. Precisely one of branch, tag, or commit must be specified.

</p>
</td>
</tr>
<tr id="new_git_repository-build_file">
<td><code>build_file</code></td>
<td>
<a href="https://bazel.build/versions/9.3.0/concepts/labels">Label</a>; optional

<p>

The file to use as the BUILD file for this repository. This attribute is an absolute label (use '@//' for the main repo). The file does not need to be named BUILD, but can be (something like BUILD.new-repo-name may work well for distinguishing it from the repository's actual BUILD files).

</p>
</td>
</tr>
<tr id="new_git_repository-build_file_content">
<td><code>build_file_content</code></td>
<td>
String; optional

<p>

The content for the BUILD file for this repository.

</p>
</td>
</tr>
<tr id="new_git_repository-canonical_id">
<td><code>canonical_id</code></td>
<td>
String; optional

<p>

A canonical ID of the file downloaded.

If specified and non-empty, Bazel will not take the file from cache, unless it
was added to the cache by a request with the same canonical ID.

If unspecified or empty, Bazel by default uses the URLs of the file as the
canonical ID. This helps catch the common mistake of updating the URLs without
also updating the hash, resulting in builds that succeed locally but fail on
machines without the file in the cache. This behavior can be disabled with
--repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0.

</p>
</td>
</tr>
<tr id="new_git_repository-commit">
<td><code>commit</code></td>
<td>
String; optional

<p>

specific commit to be checked out. Precisely one of branch, tag, or commit must be specified.

</p>
</td>
</tr>
<tr id="new_git_repository-init_submodules">
<td><code>init_submodules</code></td>
<td>
Boolean; optional

<p>

Whether to clone submodules in the repository.

</p>
</td>
</tr>
<tr id="new_git_repository-patch_args">
<td><code>patch_args</code></td>
<td>
List of strings; optional

<p>

The arguments given to the patch tool. Defaults to -p0 (see the `patch_strip` attribute), however -p1 will usually be needed for patches generated by git. If multiple -p arguments are specified, the last one will take effect.If arguments other than -p are specified, Bazel will fall back to use patch command line tool instead of the Bazel-native patch implementation. When falling back to patch command line tool and patch_tool attribute is not specified, `patch` will be used.

</p>
</td>
</tr>
<tr id="new_git_repository-patch_cmds">
<td><code>patch_cmds</code></td>
<td>
List of strings; optional

<p>

Sequence of Bash commands to be applied on Linux/Macos after patches are applied.

</p>
</td>
</tr>
<tr id="new_git_repository-patch_cmds_win">
<td><code>patch_cmds_win</code></td>
<td>
List of strings; optional

<p>

Sequence of Powershell commands to be applied on Windows after patches are applied. If this attribute is not set, patch_cmds will be executed on Windows, which requires Bash binary to exist.

</p>
</td>
</tr>
<tr id="new_git_repository-patch_strip">
<td><code>patch_strip</code></td>
<td>
Integer; optional

<p>

When set to `N`, this is equivalent to inserting `-pN` to the beginning of `patch_args`.

</p>
</td>
</tr>
<tr id="new_git_repository-patch_tool">
<td><code>patch_tool</code></td>
<td>
String; optional

<p>

The patch(1) utility to use. If this is specified, Bazel will use the specified patch tool instead of the Bazel-native patch implementation.

</p>
</td>
</tr>
<tr id="new_git_repository-patches">
<td><code>patches</code></td>
<td>
<a href="https://bazel.build/versions/9.3.0/concepts/labels">List of labels</a>; optional

<p>

A list of files that are to be applied as patches after extracting the archive. By default, it uses the Bazel-native patch implementation which doesn't support binary patch, but Bazel will fall back to use patch command line tool if `patch_tool` attribute is specified or there are arguments other than `-p` in `patch_args` attribute.

</p>
</td>
</tr>
<tr id="new_git_repository-recursive_init_submodules">
<td><code>recursive_init_submodules</code></td>
<td>
Boolean; optional

<p>

Whether to clone submodules recursively in the repository.

</p>
</td>
</tr>
<tr id="new_git_repository-remote">
<td><code>remote</code></td>
<td>
String; required

<p>

The URI of the remote Git repository

</p>
</td>
</tr>
<tr id="new_git_repository-remote_module_file_integrity">
<td><code>remote_module_file_integrity</code></td>
<td>
String; optional

<p>

For internal use only.

</p>
</td>
</tr>
<tr id="new_git_repository-remote_module_file_urls">
<td><code>remote_module_file_urls</code></td>
<td>
List of strings; optional

<p>

For internal use only.

</p>
</td>
</tr>
<tr id="new_git_repository-remote_patch_strip">
<td><code>remote_patch_strip</code></td>
<td>
Integer; optional

<p>

The number of leading slashes to be stripped from the file name in the remote patches.

</p>
</td>
</tr>
<tr id="new_git_repository-remote_patches">
<td><code>remote_patches</code></td>
<td>
<a href="https://bazel.build/versions/9.3.0/rules/lib/dict">Dictionary: String -> String</a>; optional

<p>

A map of patch file URL to its integrity value, they are applied after cloning the repository and before applying patch files from the `patches` attribute. It uses the Bazel-native patch implementation, you can specify the patch strip number with `remote_patch_strip`

</p>
</td>
</tr>
<tr id="new_git_repository-shallow_since">
<td><code>shallow_since</code></td>
<td>
String; optional

<p>

an optional date, not after the specified commit; the argument is not allowed if a tag or branch is specified (which can always be cloned with --depth=1). Setting such a date close to the specified commit may allow for a shallow clone of the repository even if the server does not support shallow fetches of arbitrary commits. Due to bugs in git's --shallow-since implementation, using this attribute is not recommended as it may result in fetch failures.

</p>
</td>
</tr>
<tr id="new_git_repository-sparse_checkout_file">
<td><code>sparse_checkout_file</code></td>
<td>
<a href="https://bazel.build/versions/9.3.0/concepts/labels">Label</a>; optional

<p>

File containing .gitignore-style patterns for a sparse checkout of files in this repository. Either `sparse_checkout_patterns` or `sparse_checkout_file` may be specified, or neither, but not both.

</p>
</td>
</tr>
<tr id="new_git_repository-sparse_checkout_patterns">
<td><code>sparse_checkout_patterns</code></td>
<td>
List of strings; optional

<p>

Sequence of patterns for a sparse checkout of files in this repository.

</p>
</td>
</tr>
<tr id="new_git_repository-strip_prefix">
<td><code>strip_prefix</code></td>
<td>
String; optional

<p>

A directory prefix to strip from the extracted files.

</p>
</td>
</tr>
<tr id="new_git_repository-tag">
<td><code>tag</code></td>
<td>
String; optional

<p>

tag in the remote repository to checked out. Precisely one of branch, tag, or commit must be specified.

</p>
</td>
</tr>
<tr id="new_git_repository-verbose">
<td><code>verbose</code></td>
<td>
Boolean; optional
</td>
</tr>
<tr id="new_git_repository-workspace_file">
<td><code>workspace_file</code></td>
<td>
<a href="https://bazel.build/versions/9.3.0/concepts/labels">Label</a>; optional

<p>

No-op attribute; do not use.

</p>
</td>
</tr>
<tr id="new_git_repository-workspace_file_content">
<td><code>workspace_file_content</code></td>
<td>
String; optional

<p>

No-op attribute; do not use.

</p>
</td>
</tr>
</tbody>
</table>

**ENVIRONMENT VARIABLES**

This repository rule depends on the following environment variables:

* `BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID`