{"id":22280922,"url":"https://github.com/jenkinsci/git-plugin","last_synced_at":"2025-12-02T20:04:21.722Z","repository":{"id":872097,"uuid":"612587","full_name":"jenkinsci/git-plugin","owner":"jenkinsci","description":"Git repository access for Jenkins jobs","archived":false,"fork":false,"pushed_at":"2025-05-02T18:31:28.000Z","size":9827,"stargazers_count":678,"open_issues_count":22,"forks_count":1065,"subscribers_count":122,"default_branch":"master","last_synced_at":"2025-05-02T19:32:45.400Z","etag":null,"topics":["git","scm"],"latest_commit_sha":null,"homepage":"https://plugins.jenkins.io/git","language":"Java","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":"magnayn/Hudson-GIT-plugin","license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/jenkinsci.png","metadata":{"files":{"readme":"README.adoc","changelog":null,"contributing":"CONTRIBUTING.adoc","funding":null,"license":"MIT-LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":".github/CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2010-04-15T21:07:21.000Z","updated_at":"2025-05-02T18:31:31.000Z","dependencies_parsed_at":"2023-02-19T04:30:26.260Z","dependency_job_id":"f7d79303-6a18-4b16-90bc-e8a10c1cdbad","html_url":"https://github.com/jenkinsci/git-plugin","commit_stats":{"total_commits":4046,"total_committers":324,"mean_commits":"12.487654320987655","dds":0.6267918932278793,"last_synced_commit":"a24001d1252f17327d199b919ff76f7f2188e037"},"previous_names":[],"tags_count":226,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jenkinsci%2Fgit-plugin","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jenkinsci%2Fgit-plugin/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jenkinsci%2Fgit-plugin/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jenkinsci%2Fgit-plugin/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/jenkinsci","download_url":"https://codeload.github.com/jenkinsci/git-plugin/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254076850,"owners_count":22010611,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["git","scm"],"created_at":"2024-12-03T16:10:11.956Z","updated_at":"2025-12-02T20:04:21.714Z","avatar_url":"https://github.com/jenkinsci.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"[[git-plugin]]\n= Git Plugin\n:toc: macro\n:toc-title:\n\n[#introduction]\n== Introduction\n\nimage::images/jenkins-and-git.png[Jenkins and Git]\n\nThe git plugin provides fundamental git operations for Jenkins projects.\nIt can poll, fetch, checkout, branch, list, merge, tag, and push repositories.\n\ntoc::[]\n\n[#changelog]\n== Changelog in https://github.com/jenkinsci/git-plugin/releases[GitHub Releases]\n\nRelease notes are recorded in https://github.com/jenkinsci/git-plugin/releases[GitHub Releases] since July 1, 2019 (git plugin 3.10.1 and later).\nPrior release notes are recorded in the git plugin repository link:https://github.com/jenkinsci/git-plugin/blob/git-4.7.2/CHANGELOG.adoc[change log].\n\n== Pipelines\n\nThe link:https://www.jenkins.io/doc/pipeline/steps/params/scmgit/[`scmGit` parameter] of the git plugin is used with the Pipeline SCM link:https://www.jenkins.io/doc/pipeline/steps/workflow-scm-step/[`checkout` step] to checkout git repositories into Pipeline workspaces.\nThe link:https://www.jenkins.io/redirect/pipeline-snippet-generator[Pipeline Syntax Snippet Generator] guides the user to select checkout options.\n\nThe link:https://youtu.be/ai1kf4ihZUo[90 second video clip] below introduces the Pipeline Syntax Snippet Generator and shows how it is used to generate steps for the Jenkins Pipeline.\n\nimage:images/pipeline-syntax.png[link=https://youtu.be/ai1kf4ihZUo]\n\n=== Multibranch Pipelines\n\nThe git plugin includes a multibranch provider for Jenkins link:https://www.jenkins.io/doc/book/pipeline/multibranch/[Multibranch Pipelines] and for Jenkins link:https://www.jenkins.io/doc/book/pipeline/multibranch/#organization-folders[Organization Folders].\nThe git plugin multibranch provider is a \"base implementation\" that uses command line git.\nUsers should prefer the multibranch implementation for their git provider when one is available.\nMultibranch implementations for specific git providers can use REST API calls to improve the Jenkins experience and add additional capabilities.\nMultibranch implementations are available for\nlink:https://docs.cloudbees.com/docs/cloudbees-ci/latest/cloud-admin-guide/github-branch-source-plugin[GitHub],\nlink:https://github.com/jenkinsci/bitbucket-branch-source-plugin/blob/master/docs/USER_GUIDE.adoc[Bitbucket],\nlink:https://plugins.jenkins.io/gitlab-branch-source/[GitLab],\nlink:https://plugins.jenkins.io/gitea/[Gitea], and\nlink:https://plugins.jenkins.io/tuleap-git-branch-source/[Tuleap].\n\nThe link:https://youtu.be/B_2FXWI6CWg[30 minute video clip] below introduces Multibranch Pipelines.\n\nimage:images/multibranch-pipeline.png[link=https://youtu.be/B_2FXWI6CWg]\n\n=== Pipeline examples\n\nThe examples below were created with the link:https://www.jenkins.io/redirect/pipeline-snippet-generator[Pipeline Syntax Snippet Generator].\nCreate your own checkout commands with the link:https://www.jenkins.io/redirect/pipeline-snippet-generator[Pipeline Syntax Snippet Generator] configured for your needs.\n\n==== Checkout with defaults\n\nCheckout from the git plugin source repository using https protocol, no credentials, and the master branch.\n\n[source,groovy]\n----\ncheckout scmGit(\n    branches: [[name: 'master']],\n    userRemoteConfigs: [[url: 'https://github.com/jenkinsci/git-plugin.git']])\n----\n\n==== Checkout with a specific branch\n\nCheckout from the git plugin source repository using https protocol, no credentials, and the `stable-3.x` branch.\n\n[source,groovy]\n----\ncheckout scmGit(\n    branches: [[name: 'stable-3.x']],\n    userRemoteConfigs: [[url: 'https://github.com/jenkinsci/git-plugin.git']])\n----\n\n==== Checkout with ssh and a private key credential\n\nCheckout from the git plugin source repository using ssh protocol, ssh private credentials, and the `v4.11.x`  branch.\nThe git plugin supports private key credentials provided by the link:https://plugins.jenkins.io/credentials[Jenkins credentials plugin].\n\n[source,groovy]\n----\ncheckout scmGit(\n    branches: [[name: 'v4.11.x']],\n    userRemoteConfigs: [[credentialsId:  'my-ssh-private-key-id',\n        url: 'ssh://github.com/jenkinsci/git-plugin.git']])\n----\n\n==== Checkout with https and a username/password credential\n\nCheckout from the git plugin source repository using https protocol, username/password credentials, and the `v4.9.x` branch.\nThe git plugin supports username/password credentials provided by the link:https://plugins.jenkins.io/credentials[Jenkins credentials plugin].\n\n[source,groovy]\n----\ncheckout scmGit(\n    branches: [[name: 'v4.9.x']],\n    userRemoteConfigs: [[credentialsId: 'my-username-password-id',\n        url: 'https://github.com/jenkinsci/git-plugin.git']])\n----\n\n==== Checkout with git large file support enabled\n\nCheckout from the git plugin source repository using https protocol with large file support enabled for the `stable-3.x` branch.\n\n[source,groovy]\n----\ncheckout scmGit(\n    branches: [[name: 'stable-3.x']],\n    extensions: [ lfs() ],\n    userRemoteConfigs: [[url: 'https://github.com/jenkinsci/git-plugin.git']])\n----\n\n==== Checkout without fetching tags (advanced clone behavior)\n\nCheckout from the git plugin source repository using https with no credentials and without tags.\nThis can save time and disk space when you want to access the repository without considering tags.\n\n[source,groovy]\n----\ncheckout scmGit(\n    branches: [[name: 'master']],\n    extensions: [ cloneOption(noTags: true) ],\n    userRemoteConfigs: [[url: 'https://github.com/jenkinsci/git-plugin.git']])\n----\n\n==== Checkout with a shallow clone to reduce data traffic\n\nCheckout from the workspace cleanup plugin source repository using https without credentials, a default branch, and a shallow clone.\nShallow clone requests a limited number of commits from the tip of the requested branch and may save time, data transfer, and disk space.\n\n[source,groovy]\n----\ncheckout scmGit(\n    branches: [[name: '*/master']],\n    extensions: [ cloneOption(shallow: true) ],\n    userRemoteConfigs: [[url: 'https://github.com/jenkinsci/ws-cleanup-plugin']])\n----\n\n==== Checkout with a narrow refspec\n\nCheckout from the workspace cleanup plugin source repository using https without credentials, the `master` branch, and with a refspec specific to the master branch.\nThis can save time, data transfer, and disk space when you only need to access the references specified by the refspec.\n\n[source,groovy]\n----\ncheckout scmGit(\n    branches: [[name: '*/master']],\n    extensions: [ cloneOption(honorRefspec: true) ],\n    userRemoteConfigs: [[refspec: '+refs/heads/master:refs/remotes/origin/master',\n        url: 'https://github.com/jenkinsci/ws-cleanup-plugin']])\n----\n\n==== Checkout and prune stale remote branches\n\nCheckout from the workspace cleanup plugin source repository using https without credentials and with prune tags and prune branches extension enabled.\nThis removes remote tracking branches and tags from the local workspace if they no longer exist on the remote.\n\n[source,groovy]\n----\ncheckout scmGit(\n    branches: [[name: 'master']],\n    extensions: [ pruneStaleBranch(), pruneTags(true) ],\n    userRemoteConfigs: [[url: 'https://github.com/jenkinsci/ws-cleanup-plugin']])\n----\n\n==== Wipe out repository before checkout\n\nRemove all files in the workspace before a checkout from the workspace cleanup plugin source repository using https without credentials, a default branch.\nEnsures a fully fresh workspace.\n\n[source,groovy]\n----\ndeleteDir()\ncheckout scmGit(\n    branches: [[name: '*/master']],\n    userRemoteConfigs: [[url: 'https://github.com/jenkinsci/ws-cleanup-plugin']])\n----\n\n[#credential-binding]\n=== Git Credentials Binding\n\nThe git plugin provides `Git Username and Password` binding that allows authenticated git operations over *HTTP* and *HTTPS* protocols using command line git in a Pipeline job.\n\nThe git credential bindings are accessible through the link:https://www.jenkins.io/doc/pipeline/steps/credentials-binding/#withcredentials-bind-credentials-to-variables[`withCredentials`] step of the link:https://plugins.jenkins.io/credentials-binding/[Credentials Binding] plugin.\nThe binding retrieves credentials from the link:https://plugins.jenkins.io/credentials/[Credentials] plugin.\n\n==== Git Username and Password Binding\n\nThis binding provides authentication support over *HTTP* protocol using command line git in a Pipeline job.\n\nProcedure::\n\n. Click the Pipeline Syntax _Snippet Generator_ and choose the `withCredentials` step, add Git Username and Password binding.\n. Choose the required credentials and Git tool name, specific to the generated Pipeline snippet.\n\nimage:images/git-credentials-usernamepassword-binding-pipline-job.png[Git-Username-and Password-Binding-Pipeline-Job]\n\nTwo variable bindings are used, `GIT_USERNAME` and `GIT_PASSWORD`, to pass the username and password to `sh`, `bat`, and `powershell` steps inside the `withCredentials` block of a Pipeline job.\nThe variable bindings are available even if the `JGit` or `JGit with Apache HTTP Client` git implementation is being used.\n\n.Shell example\n```groovy\nwithCredentials([gitUsernamePassword(credentialsId: 'my-credentials-id',\n                 gitToolName: 'git-tool')]) {\n  sh 'git fetch --all'\n}\n```\n\n.Batch example\n```groovy\nwithCredentials([gitUsernamePassword(credentialsId: 'my-credentials-id',\n                 gitToolName: 'git-tool')]) {\n  bat 'git submodule update --init --recursive'\n}\n```\n\n.Powershell example\n```groovy\nwithCredentials([gitUsernamePassword(credentialsId: 'my-credentials-id',\n                 gitToolName: 'git-tool')]) {\n  powershell 'git push'\n}\n```\n[#configuration]\n== [[GitPlugin-ProjectConfiguration]]Configuration\n\n[#using-repositories]\n=== Repositories\n\nimage:images/git-repository-configuration.png[Repository Configuration]\n\nThe git plugin fetches commits from one or more remote repositories and performs a checkout in the agent workspace.\nRepositories and their related information include:\n\nRepository URL::\n\n  The URL of the remote repository.\n  The git plugin passes the remote repository URL to the git implementation (command line or JGit).\n  Valid repository URL's include `https`, `ssh`, `scp`, `git`, `local file`, and other forms.\n  Valid repository URL forms are described in the link:https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_protocols[git documentation].\n\nCredentials::\n\n  Credentials are defined using the link:https://plugins.jenkins.io/credentials[Jenkins credentials plugin].\n  They are selected from a drop-down list and their identifier is stored in the job definition.\n  Refer to \u003c\u003cusing-credentials,using credentials\u003e\u003e for more details on supported credential types.\n\nName::\n\n  Git uses a short name to simplify user references to the URL of the remote repository.\n  The default short name is `origin`.\n  Other values may be assigned and then used throughout the job definition to refer to the remote repository.\n\nRefspec::\n\n  A refspec maps remote branches to local references.\n  It defines the branches and tags which will be fetched from the remote repository into the agent workspace.\n+\nA refspec defines the remote references that will be retrieved and how they map to local references.\nIf left blank, it will default to the normal `git fetch` behavior and will retrieve all branches.\nThis default behavior is sufficient for most cases.\n+\nThe default refspec is `+refs/heads/*:refs/remotes/REPOSITORYNAME/` where REPOSITORYNAME is the value you specify in the above repository \"Name\" field.\nThe default refspec retrieves all branches.\nIf a checkout only needs one branch, then a more restrictive refspec can reduce the data transfer from the remote repository to the agent workspace.\nFor example, `+refs/heads/master:refs/remotes/origin/master` will retrieve only the master branch and nothing else.\n+\nThe refspec can be used with the \u003c\u003chonor-refspec-on-initial-clone,honor refspec on initial clone\u003e\u003e option in the \u003c\u003cadvanced-clone-behaviours,advanced clone behaviors\u003e\u003e to limit the number of remote branches mapped to local references.\nIf \"honor refspec on initial clone\" is not enabled, then a default refspec for its initial fetch.\nThis maintains compatibility with previous behavior and allows the job definition to decide if the refspec should be honored on initial clone.\n+\nMultiple refspecs can be entered by separating them with a space character.\nThe refspec value `+refs/heads/master:refs/remotes/origin/master +refs/heads/develop:refs/remotes/origin/develop` retrieves the master branch and the develop branch and nothing else.\n+\nRefer to the link:https://git-scm.com/book/en/v2/Git-Internals-The-Refspec[git refspec documentation] for more refspec details.\n\n[#using-credentials]\n=== Using Credentials\n\nThe git plugin supports username / password credentials and private key credentials provided by the\nhttps://plugins.jenkins.io/credentials[Jenkins credentials plugin].\nIt does not support other credential types like secret text, secret file, or certificates.\nSelect credentials from the job definition drop down menu or enter their identifiers in Pipeline job definitions.\n\nWhen the remote repository is accessed with the **HTTP or HTTPS protocols**, the plugin requires a **username / password credential**.\nOther credential types will not work with HTTP or HTTPS protocols.\n\nWhen the remote repository is accessed with the **ssh protocol**, the plugin requires an **ssh private key credential**.\nOther credential types will not work with the ssh protocol.\n\n[#push-notification-from-repository]\n=== [[GitPlugin-Pushnotificationfromrepository]]Push Notification From Repository\n\nTo minimize the delay between a push and a build, configure the remote repository to use a Webhook to notify Jenkins of changes to the repository.\nRefer to webhook documentation for your repository:\n\n* link:https://plugins.jenkins.io/github/#plugin-content-github-hook-trigger-for-gitscm-polling[GitHub]\n* link:https://plugins.jenkins.io/bitbucket[Bitbucket]\n* link:https://plugins.jenkins.io/gitlab-branch-source[GitLab]\n* link:https://github.com/jenkinsci/gitea-plugin/blob/master/docs/README.md[Gitea]\n* link:https://docs.tuleap.org/user-guide/code-versioning/git.html#jenkins-webhooks[Tuleap]\n\nOther git repositories can use a link:https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks[post-receive hook] in the remote repository to notify Jenkins of changes.  The `notifyCommit` endpoint can take four parameters.\n\n* `url` (required) should match the URL in which a Jenkins job is configured to clone.\n* `branches` (optional) is a comma separated list of one or more branches meant for multi-branch pipelines.\n* `sha1` (optional) the SHA1 Git commit hash which triggered the notification.\n* `token` (optional) a secret token which must match the Jenkins configuration.  Jenkins ignores non-matching token requests.\n\nAdd the following line in your `hooks/post-receive` file on the git server, replacing \u003cURL of the Git repository\u003e with the fully qualified URL you use when cloning the repository, and replacing \u003cAccess token\u003e with a token generated by a Jenkins administrator using the \"Git plugin notifyCommit access tokens\" section of the \"Configure Global Security\" page.\n\n....\ncurl \"http://yourserver/git/notifyCommit?url=\u003cURL of the Git repository\u003e\u0026token=\u003cAccess token\u003e\"\n....\n\nThis will scan all the jobs that:\n\n* Have Build Triggers \u003e Poll SCM enabled.  No polling schedule is required.\n* Are configured to build the repository at the specified URL\n\nFor jobs that meet these conditions, polling will be triggered.\nIf polling finds a change worthy of a build, a build will be triggered.\n\nThis allows a notify script to remain the same for all Jenkins jobs.\nOr if you have multiple repositories under a single repository host application (such as Gitosis), you can share a single post-receive hook script with all the repositories.\n\nWhen notifyCommit is successful, the list of triggered projects is returned.\n\nThe `token` parameter is required by default as a security measure, but can be disabled by the following link:https://www.jenkins.io/doc/book/managing/system-properties/[system property]:\n\n....\nhudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL\n....\n\nIt has two modes:\n\n* `disabled-for-polling` - Allows unauthenticated requests as long as they only request polling of the repository supplied in the `url` query parameter. Prohibits unauthenticated requests that attempt to schedule a build immediately by providing a\n`sha1` query parameter.\n* `disabled` - Fully disables the access token mechanism and allows all requests to `notifyCommit`\nto be unauthenticated. *This option is insecure and is not recommended.*\n\nYou can set the `NOTIFY_COMMIT_ACCESS_CONTROL` value with either a link:https://www.jenkins.io/doc/book/managing/system-properties/[system property] or a link:https://www.jenkins.io/doc/book/managing/groovy-hook-scripts/[Groovy hook script].\n\n[[using-a-system-property-push-notification]]\nUsing a system property::\n\nThe `NOTIFY_COMMIT_ACCESS_CONTROL` value can be set from the command line that starts Jenkins.\nThis method is useful for environments where initial Jenkins settings are managed with command line arguments.\n+\n....\njava -Dhudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL=disabled-for-polling -jar jenkins.war\n....\n\n[[using-a-groovy-script-push-notification]]\n Using a Groovy script::\n\nThe `NOTIFY_COMMIT_ACCESS_CONTROL` value can be set using a Groovy script placed in the `init.groovy.d` subdirectory of the Jenkins home directory.\nThis method is useful for environments where Jenkins settings are managed with link:https://www.jenkins.io/doc/book/managing/groovy-hook-scripts/#post-initialization-script-init-hook[Groovy post-initialization scripts].\n+\n----\nhudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL='disabled-for-polling'\n----\n\n[#enabling-jgit]\n=== Enabling JGit\n\nSee the link:https://plugins.jenkins.io/git-client/#plugin-content-enabling-jgit[git client plugin documentation] for instructions to enable JGit.\nJGit becomes available throughout Jenkins once it has been enabled.\n\n[#global-configuration]\n=== [[GitPlugin-Configuration]]Global Configuration\n\nimage:images/git-global-configuration.png[Global Configuration]\n\nIn the `Configure System` page, the Git Plugin provides the following options:\n\n[[global-config-user-name]]\nGlobal Config user.name Value::\n\n  Defines the default git user name that will be assigned when git commits a change from Jenkins.\n  For example, `Janice Examplesperson`.\n  This can be overridden by individual projects with the \u003c\u003ccustom-user-name-e-mail-address\u003e\u003e extension.\n\n[[global-config-user-email]]\nGlobal Config user.email Value::\n\n  Defines the default git user e-mail that will be assigned when git commits a change from Jenkins.\n  For example, `janice.examplesperson@example.com`.\n  This can be overridden by individual projects with the \u003c\u003ccustom-user-name-e-mail-address\u003e\u003e extension.\n\n[[create-new-accounts-based-on-author-email]]\nCreate new accounts based on author/committer's email::\n\n  New user accounts are created in Jenkins for committers and authors identified in changelogs.\n  The new user accounts are added to the internal Jenkins database.\n  The e-mail address is used as the id of the account.\n\n[[show-the-entire-commit-summary-in-changes]]\nShow the entire commit summary in changes::\n\n  The `changes` page for each job would truncate the change summary prior to git plugin 4.0.\n  With the release of git plugin 4.0, the default was changed to show the complete change summary.\n  Administrators that want to restore the old behavior may disable this setting.\n\n[[hide-credentials]]\nHide credential usage in job output::\n\n  If checked, the console log will not show the credential identifier used to clone a repository.\n\n[[disable-performance-enhancements]]\nDisable performance enhancements::\n\n  If JGit and command line git are both enabled on an agent, the git plugin uses a \"git tool chooser\" to choose a preferred git implementation.\n  The preferred git implementation depends on the size of the repository and the git plugin features requested by the job.\n  If the repository size is *less than* the JGit repository size threshold and the git features of the job are all implemented in JGit, then JGit is used.\n  If the repository size is *greater than* the JGit repository size threshold or the job requires git features that are not implemented in JGit, then command line git is used.\n+\nIf checked, the plugin will disable the feature that recommends a git implementation on the basis of the size of a repository.\nThis switch may be used in case of a bug in the performance improvement feature.\nIf you enable this setting, please report a git plugin issue that describes why you needed to enable it.\n\n[[preserve-second-fetch-during-checkout]]\nPreserve second fetch during initial checkout::\n\n  If checked, the initial checkout step will not avoid the second fetch.\n  Git plugin versions prior to git plugin 4.4 would perform two fetch operations during the initial repository checkout.\n  Git plugin 4.4 removes the second fetch operation in most cases.\n  Enabling this option will restore the second fetch operation.\n  This setting is only needed if there is a bug in the redundant fetch removal logic.\n  If you enable this setting, please report a git plugin issue that describes why you needed to enable it.\n\n[[do-not-add-git-tag-action-to-jobs]]\nAdd git tag action to jobs::\n\n  If checked, the git tag action will be added to any builds that happen *after* the box is checked.\n  Prior to git plugin 4.5.0, the git tag action was always added.\n  Git plugin 4.5.0 and later will not add the git tag action to new builds unless the administrator enables it.\n+\nThe git tag action allows a user to apply a tag to the git repository in the workspace based on the git commit used in the build applying the tag.\nThe git plugin does *not* push the applied tag to any other location.\nIf the workspace is removed, the tag that was applied is lost.\nTagging a workspace made sense when using centralized repositories that automatically applied the tag to the centralized repository.\nApplying a git tag in an agent workspace doesn't have many practical uses.\n\n[#configuration-as-code]\n=== Configuration as code\n\nThe global settings of the git plugin can be defined with the Jenkins link:https://plugins.jenkins.io/configuration-as-code/[configuration as code plugin].\nDetailed descriptions of the individual settings are available in the link:#global-configuration[global configuration settings] section of this document.\n\nAn example configuration might look like this:\n\n[,yaml]\n----\nsecurity:\n  gitHooks:\n    allowedOnAgents: false\n    allowedOnController: false\nunclassified:\n  scmGit:\n    addGitTagAction: false\n    allowSecondFetch: false\n    createAccountBasedOnEmail: false\n    disableGitToolChooser: false\n    globalConfigEmail: \"jenkins-user@example.com\"\n    globalConfigName: \"jenkins-user\"\n    hideCredentials: false\n    showEntireCommitSummaryInChanges: true\n    useExistingAccountWithSameEmail: false\n----\n\n[#security-configuration]\n\n=== Security Configuration\n\nimage:/images/git-security-configuration.png[Security Configuration]\n\nIn the `Configure Global Security` page, the Git Plugin provides the following option:\n\n[[global-security-git-hooks]]\nGit Hooks::\n\n  link:https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks[Git hooks] allow scripts to be invoked when certain important git repository actions occur.\n  This configuration controls the execution of client-side hooks on the controller and on agents.\n  It is recommended that git hooks be **disabled** on the controller and on agents.\n+\nMost git repositories do not use hooks in the repository and do not need repository hooks.\nIn those rare cases where repository hooks are needed, it is highly recommended that they are **disabled** on the Jenkins controller and on Jenkins agents.\n+\nClient-side hooks are **not** copied when the repository is cloned by Jenkins using the inbuilt SCM methods.\nHowever, client-side hooks might be installed in a repository by build steps or by misconfiguration.\n+\nIf hook scripts are allowed, a client-side hook script installed in a repository will execute when the matching git operation is performed.\nFor example, if hooks are allowed and a git repository includes a `post-checkout` hook, the hook script will run after any checkout in that repository.\nIf hooks are allowed and a git repository includes a `pre-auto-gc` hook, the hook script will run before any automatic git garbage collection task.\n+\nSee link:https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks[\"Customizing Git - Git Hooks\"] for more details about git repository hooks.\n\n[#repository-browser]\n=== Repository Browser\n\nimage:images/git-repository-browser.png[Repository Browser]\n\nA Repository Browser adds links in \"changes\" views within Jenkins to an external system for browsing the details of those changes.\nThe \"Auto\" selection attempts to infer the repository browser from the \"Repository URL\" and can detect cloud versions of GitHub, Bitbucket and GitLab.\n\nRepository browsers include:\n\n[#assemblaweb-repository-browser]\n==== AssemblaWeb\n\nimage:images/git-repository-browser-assemblaweb.png[Assembla Repository Browser]\n\nRepository browser for git repositories hosted by link:https://www.assembla.com/home[Assembla].\nOptions include:\n\n[[assembla-git-url]]\nAssembla Git URL::\n\n  Root URL serving this Assembla repository.\n  For example, `\\https://app.assembla.com/spaces/git-plugin/git/source`\n\n[#fisheye-repository-browser]\n==== FishEye\n\nimage:images/git-repository-browser-fisheye.png[FishEye Repository Browser]\n\nRepository browser for git repositories hosted by link:https://www.atlassian.com/software/fisheye[Atlassian Fisheye].\nOptions include:\n\n[[fisheye-url]]\nURL::\n\n  Root URL serving this FishEye repository.\n  For example, `\\https://fisheye.example.com/browse/my-project`\n\n[#kiln-repository-browser]\n==== Kiln\n\nimage:images/git-repository-browser-kiln.png[Kiln Repository Browser]\n\nRepository browser for git repositories hosted by link:http://www.fogbugz.com/version-control[Kiln].\nOptions include:\n\n[[kiln-url]]\nURL::\n\n  Root URL serving this Kiln repository.\n  For example, `\\https://kiln.example.com/username/my-project`\n\n[#visual-studio-team-services-repository-browser]\n==== Microsoft Team Foundation Server/Visual Studio Team Services\n\nimage:images/git-repository-browser-microsoft.png[Microsoft Repository Browser]\n\nRepository browser for git repositories hosted by link:https://azure.microsoft.com/en-us/solutions/devops/[Azure DevOps].\nOptions include:\n\n[[visual-studio-repository-url-or-name]]\nURL or name::\n\n  Root URL serving this Azure DevOps repository.\n  For example, `\\https://dev.azure.com/example/_git/my-project`\n\n[bitbucketweb-repository-browser]\n==== bitbucketweb\n\nimage:images/git-repository-browser-bitbucket.png[Bitbucket Repository Browser]\n\nRepository browser for git repositories hosted by link:https://bitbucket.org/[Bitbucket].\nOptions include:\n\n[[bitbucketweb-url]]\nURL::\n\n  Root URL serving this Bitbucket repository.\n  For example, `\\https://bitbucket.org/username/my-project`\n\n[bitbucketserver-repository-browser]\n==== bitbucketserver\n\nimage:images/git-repository-browser-bitbucketserver.png[Bitbucket Server Repository Browser]\n\nRepository browser for git repositories hosted by an on-premises Bitbucket Server installation.\nOptions include:\n\n[[bitbucketserver-url]]\nURL::\n\n  Root URL serving this Bitbucket repository.\n  For example, `\\https://bitbucket.example.com/username/my-project`\n\n[#cgit-repository-browser]\n==== cgit\n\nimage:images/git-repository-browser-cgit.png[CGit Repository Browser]\n\nRepository browser for git repositories hosted by link:https://git.zx2c4.com/cgit/[cgit].\nOptions include:\n\n[[cgit-url]]\nURL::\n\n  Root URL serving this cgit repository.\n  For example, `\\https://git.zx2c4.com/cgit/`\n\n[#gitblit-repository-browser]\n==== gitblit\n\nimage:images/git-repository-browser-gitblit.png[GitBlit Repository Browser]\n\n[[gitblit-url]]\nGitBlit root url::\n\n  Root URL serving this GitBlit repository.\n  For example, `\\https://gitblit.example.com/`\n\n[[gitblit-project-name]]\nProject name in GitBlit::\n\n  Name of the GitBlit project.\n  For example, `my-project`\n\n[#githubweb-repository-browser]\n==== githubweb\n\nimage:images/git-repository-browser-github.png[GitHub Repository Browser]\n\nRepository browser for git repositories hosted by link:https://github.com//[GitHub].\nOptions include:\n\n[[githubweb-url]]\nURL::\n\n  Root URL serving this GitHub repository.\n  For example, `\\https://github.example.com/username/my-project`\n\n[#gitiles-repository-browser]\n==== gitiles\n\nimage:images/git-repository-browser-gitiles.png[Gitiles Repository Browser]\n\nRepository browser for git repositories hosted by link:https://gerrit.googlesource.com/gitiles/[Gitiles].\nOptions include:\n\n[[githubweb-url]]\ngitiles root url::\n\n  Root URL serving this Gitiles repository.\n  For example, `\\https://gerrit.googlesource.com/gitiles/`\n\n[#gitlab-self-hosted-repository-browser]\n[#gitlab-com-repository-browser]\n==== gitlab\n\nimage:images/git-repository-browser-gitlab.png[GitLab Repository Browser]\n\nRepository browser for git repositories hosted by link:https://gitlab.com/[GitLab].\nOptions include:\n\n[[gitlab-url]]\nURL::\n\n  Root URL serving this GitLab repository.\n  For example, `\\https://gitlab.example.com/username/my-project`\n\n[[gitlab-version]]\nVersion::\n\n  Major and minor version of GitLab you use, such as 15.6.\n  If you don't specify a version, a modern version of GitLab (\u003e= 8.0) is assumed.\n  For example, `15.6`\n\n[#gitlist-repository-browser]\n==== gitlist\n\nimage:images/git-repository-browser-gitlist.png[Gitlist Repository Browser]\n\nRepository browser for git repositories hosted by link:https://gitlist.org/[GitList].\nOptions include:\n\n[[gitlist-url]]\nURL::\n\n  Root URL serving this GitList repository.\n  For example, `\\https://gitlist.example.com/username/my-project`\n\n[#gitoriousweb-repository-browser]\n==== gitoriousweb\n\nGitorious was acquired in 2015.\nThis browser is *deprecated*.\n\n[[gitoriousweb-url]]\nURL::\n\n  Root URL serving this Gitorious repository.\n  For example, `\\https://gitorious.org/username/my-project`\n\n[#gitweb-repository-browser]\n==== gitweb\n\nimage:images/git-repository-browser-gitweb.png[Gitweb Repository Browser]\n\nRepository browser for git repositories hosted by link:https://git-scm.com/docs/gitweb[GitWeb].\nOptions include:\n\n[[gitweb-url]]\nURL::\n\n  Root URL serving this GitWeb repository.\n  For example, `\\https://gitweb.example.com/username/my-project`\n\n[#gogs-repository-browser]\n==== gogs\n\nimage:images/git-repository-browser-gogs.png[Gogs Repository Browser]\n\nRepository browser for git repositories hosted by link:https://gogs.io/[Gogs].\nOptions include:\n\n[[gogs-url]]\nURL::\n\n  Root URL serving this Gogs repository.\n  For example, `\\https://gogs.example.com/username/my-project`\n\n[#phabricator-repository-browser]\n==== phabricator\n\nEffective June 1, 2021, Phabricator is link:https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/[no longer actively maintained].\nThis browser is *deprecated*.\n\n[[phabricator-url]]\nURL::\n\n  Root URL serving this Phabricator repository.\n  For example, `\\https://phabricator.example.com/`\n\n[[phabricator-repository-name]]\nRepository name in Phab::\n\n  Name of the Phabricator repository.\n  For example, `my-project`\n\n[#redmineweb-repository-browser]\n==== redmineweb\n\nimage:images/git-repository-browser-redmine.png[Redmine Repository Browser]\n\nRepository browser for git repositories hosted by link:https://www.redmine.org/[Redmine].\nOptions include:\n\n[[redmineweb-url]]\nURL::\n\n  Root URL serving this Redmine repository.\n  For example, `\\https://redmine.example.com/username/projects/my-project/repository`\n\n[#rhodecode-repository-browser]\n==== rhodecode\n\nimage:images/git-repository-browser-rhodecode.png[RhodeCode Repository Browser]\n\nRepository browser for git repositories hosted by link:https://thodecode.com/[RhodeCode].\nOptions include:\n\n[[rhodecode-url]]\nURL::\n\n  Root URL serving this RhodeCode repository.\n  For example, `\\https://rhodecode.example.com/username/my-project`\n\n[#stash-repository-browser]\n==== stash\n\nimage:images/git-repository-browser-stash.png[Stash Repository Browser]\n\nStash is now called *BitBucket Server*.\nRepository browser for git repositories hosted by link:https://www.atlassian.com/software/bitbucket[BitBucket Server].\nOptions include:\n\n[[stash-url]]\nURL::\n\n  Root URL serving this Stash repository.\n  For example, `\\https://stash.example.com/username/my-project`\n\n[#viewgit-repository-browser]\n==== viewgit\n\nimage:images/git-repository-browser-viewgit.png[Viewgit Repository Browser]\n\nRepository browser for git repositories hosted by link:https://www.openhub.net/p/viewgit[viewgit].\nOptions include:\n\n[[viewgit-root-url]]\nViewGit root url::\n\n  Root URL serving this ViewGit repository.\n  For example, `\\https://viewgit.example.com/`\n\n[[viewgit-project-name]]\nProject Name in ViewGit::\n\n  ViewGit project name.\n  For example, `my-project`\n\n[#git-bindings]\n== Git Credential Binding\n\nThe git plugin provides one binding to support authenticated git operations over *HTTP* or *HTTPS* protocol, namely `Git Username and Password`.\nThe git plugin depends on the Credential Binding Plugin to support these bindings.\n\nTo access the `Git Username and Password` binding in a Pipeline job, visit \u003c\u003ccredential-binding\u003e\u003e\n\nFreestyle projects can use git credential binding with the following steps:\n\n. Check the box _Use secret text(s) or file(s)_, add Git Username and Password binding.\n\n. Choose the required credentials and Git tool name.\n\nimage:images/git-credentials-usernamepassword-binding-freestyle-project.png[Git-Username-and Password-Binding-Freestyle-project]\n\nTwo variable bindings are used, `GIT_USERNAME` and `GIT_PASSWORD`, to pass the username and password to shell, batch, and powershell steps in a Freestyle job.\nThe variable bindings are available even if the `JGit` or `JGit with Apache HTTP Client` git implementation is being used.\n\n[#extensions]\n== Extensions\n\nExtensions add new behavior or modify existing plugin behavior for different uses.\nExtensions help users more precisely tune the plugin to meet their needs.\n\nExtensions include:\n\n- \u003c\u003cclone-extensions\u003e\u003e\n- \u003c\u003ccheckout-extensions\u003e\u003e\n- \u003c\u003cchangelog-extensions\u003e\u003e\n- \u003c\u003ctagging-extensions\u003e\u003e\n- \u003c\u003cbuild-initiation-extensions\u003e\u003e\n- \u003c\u003cmerge-extensions\u003e\u003e\n- \u003c\u003cdeprecated-extensions\u003e\u003e\n\n[#clone-extensions]\n=== Clone Extensions\n\nClone extensions modify the git operations that retrieve remote changes into the agent workspace.\nThe extensions can adjust the amount of history retrieved, how long the retrieval is allowed to run, and other retrieval details.\n\n[#advanced-clone-behaviours]\n==== Advanced clone behaviours\n\nimage:images/git-advanced-clone-behaviours.png[Advanced clone behaviours]\n\nAdvanced clone behaviors modify the `link:https://git-scm.com/docs/git-clone[git clone]` and `link:https://git-scm.com/docs/git-fetch[git fetch]` commands.\nThey control:\n\n* breadth of history retrieval (refspecs)\n* depth of history retrieval (shallow clone)\n* disc space use (reference repositories)\n* duration of the command (timeout)\n* tag retrieval\n\nAdvanced clone behaviors include:\n\n[[honor-refspec-on-initial-clone]]\nHonor refspec on initial clone::\n\n  Perform initial clone using the refspec defined for the repository.\n  This can save time, data transfer and disk space when you only need to access the references specified by the refspec.\n  If this is not enabled, then the plugin default refspec includes **all** remote branches.\n\nShallow clone::\n\n  Perform a shallow clone by requesting a limited number of commits from the tip of the requested branch(es).\n  Git will not download the complete history of the project.\n  This can save time and disk space when you just want to access the latest version of a repository.\n\nShallow clone depth::\n\n  Set shallow clone depth to the specified number of commits.\n  Git will only download `depth` commits from the remote repository, saving time and disk space.\n\nPath of the reference repo to use during clone::\n\n  Specify a folder containing a repository that will be used by git as a reference during clone operations.\n  This option will be ignored if the folder is not available on the agent.\n\nTimeout (in minutes) for clone and fetch operations::\n\n  Specify a timeout (in minutes) for clone and fetch operations.\n\nFetch tags::\n\n  Deselect this to perform a clone without tags, saving time and disk space when you want to access only what is specified by the refspec, without considering any repository tags.\n\n[#prune-stale-remote-tracking-branches]\n==== Prune stale remote tracking branches\n\nimage:images/git-prune-stale-remote-tracking-branches.png[Prune stale remote tracking branches]\n\nRemoves remote tracking branches from the local workspace if they no longer exist on the remote.\nSee `link:https://git-scm.com/docs/git-remote#Documentation/git-remote.txt-empruneem[git remote prune]` and `link:https://git-scm.com/docs/git-fetch#_pruning[git fetch --prune]` for more details.\n\n[#prune-stale-tags]\n==== Prune stale tags\n\nimage:images/git-prune-stale-tags.png[Prune stale tags]\n\nRemoves tags from the local workspace before fetch if they no longer exist on the remote.\nIf stale tags are not pruned, deletion of a remote tag will not remove the local tag in the workspace.\nIf the local tag already exists in the workspace, git correctly refuses to create the tag again.\nPruning stale tags allows the local workspace to create a tag with the same name as a tag which was removed from the remote.\n\n[#checkout-extensions]\n=== Checkout Extensions\n\nCheckout extensions modify the git operations that place files in the workspace from the git repository on the agent.\nThe extensions can adjust the maximum duration of the checkout operation, the use and behavior of git submodules, the location of the workspace on the disc, and more.\n\n[#advanced-checkout-behaviors]\n==== Advanced checkout behaviors\n\nimage:images/git-advanced-checkout-behaviors.png[Advanced checkout behaviors]\n\nAdvanced checkout behaviors modify the `link:https://git-scm.com/docs/git-checkout[git checkout]` command.\nAdvanced checkout behaviors include\n\nTimeout (in minutes) for checkout operation::\n\n  Specify a timeout (in minutes) for checkout.\n  The checkout is stopped if the timeout is exceeded.\n  Checkout timeout is usually only required with slow file systems or large repositories.\n\n[#advanced-sub-modules-behaviours]\n==== Advanced sub-modules behaviours\n\nimage:images/git-advanced-sub-modules-behaviours.png[Advanced sub-modules behaviours]\n\nAdvanced sub-modules behaviors modify the `link:https://git-scm.com/docs/git-submodule[git submodule]` commands.\nThey control:\n\n* depth of history retrieval (shallow clone)\n* disc space use (reference repositories)\n* credential use\n* duration of the command (timeout)\n* concurrent threads used to fetch submodules\n\nAdvanced sub-modules include:\n\nDisable submodules processing::\n\n  Ignore submodules in the repository.\n\nRecursively update submodules::\n\n  Retrieve all submodules recursively. Without this option, submodules\n  which contain other submodules will ignore the contained submodules.\n\nUpdate tracking submodules to tip of branch::\n\n  Retrieve the tip of the configured branch in .gitmodules.\n\nUse credentials from default remote of parent repository::\n\n  Use credentials from the default remote of the parent project.\n  Submodule updates do not use credentials by default.\n  Enabling this extension will provide the parent repository credentials to each of the submodule repositories.\n  Submodule credentials require that the submodule repository must accept the same credentials as the parent project.\n  If the parent project is cloned with https, then the authenticated submodule references must use https as well.\n  If the parent project is cloned with ssh, then the authenticated submodule references must use ssh as well.\n\nPath of the reference repo to use during submodule update::\n\n  Folder containing a repository that will be used by git as a reference during submodule clone operations.\n  This option will be ignored if the folder is not available on the agent running the build.\n  A reference repository may contain multiple subprojects.\n  See the combining repositories section for more details.\n\nTimeout (in minutes) for submodule operations::\n\n  Specify a timeout (in minutes) for submodules operations.\n  This option overrides the default timeout.\n\nNumber of threads to use when updating submodules::\n\n  Number of parallel processes to be used when updating submodules.\n  Default is to use a single thread for submodule updates\n\nShallow clone::\n\n  Perform shallow clone of submodules.\n  Git will not download the complete history of the project, saving time and disk space.\n\nShallow clone depth::\n\n  Set shallow clone depth for submodules.\n  Git will only download recent history of the project, saving time and disk space.\n\n[#checkout-to-a-sub-directory]\n==== Checkout to a sub-directory\n\nimage:images/git-checkout-to-a-sub-directory.png[Checkout to a sub-directory]\n\nCheckout to a subdirectory of the workspace instead of using the workspace root.\n\nThis extension should **not** be used in Jenkins Pipeline (either declarative or scripted).\nJenkins Pipeline already provides standard techniques for checkout to a subdirectory.\nUse `ws` and `dir` in Jenkins Pipeline rather than this extension.\n\nLocal subdirectory for repo::\n\n  Name of the local directory (relative to the workspace root) for the git repository checkout.\n  If left empty, the workspace root itself will be used.\n\n[#checkout-to-specific-local-branch]\n==== Checkout to specific local branch\n\nimage:images/git-checkout-to-specific-local-branch.png[Checkout to specific local branch]\n\nBranch name::\n\n  If given, checkout the revision to build as HEAD on the named branch.\n  If value is an empty string or \"**\", then the branch name is computed from the remote branch without the origin.\n  In that case, a remote branch 'origin/master' will be checked out to a local branch named 'master', and a remote branch 'origin/develop/new-feature' will be checked out to a local branch named 'develop/new-feature'.\n  If a specific revision and not branch HEAD is checked out, then 'detached' will be used as the local branch name.\n\n[#wipe-out-repository-and-force-clone]\n==== Wipe out repository and force clone\n\nimage:images/git-wipe-out-repository-and-force-clone.png[Wipe out repository and force clone]\n\nDelete the contents of the workspace before build and before checkout.\nDeletes the git repository inside the workspace and will force a full clone.\n\n[clean-after-checkout]\n==== Clean after checkout\n\nimage:images/git-clean-after-checkout.png[Clean after checkout]\n\nClean the workspace *after* every checkout by deleting all untracked files and directories, including those which are specified in `.gitignore`.\nResets all tracked files to their versioned state.\nEnsures that the workspace is in the same state as if clone and checkout were performed in a new workspace.\nReduces the risk that current build will be affected by files generated by prior builds.\nDoes not remove files outside the workspace (like temporary files or cache files).\nDoes not remove files in the `.git` repository of the workspace.\n\nDelete untracked nested repositories::\n\n  Remove subdirectories which contain `.git` subdirectories if this option is enabled.\n  This is implemented in command line git as `git clean -xffd`.\n  Refer to the link:https://git-scm.com/docs/git-clean[git clean manual page] for more information.\n\n[#clean-before-checkout]\n==== Clean before checkout\n\nimage:images/git-clean-before-checkout.png[Clean before checkout]\n\nClean the workspace *before* every checkout by deleting all untracked files and directories, including those which are specified in .gitignore.\nResets all tracked files to their versioned state.\nEnsures that the workspace is in the same state as if cloned and checkout were performed in a new workspace.\nReduces the risk that current build will be affected by files generated by prior builds.\nDoes not remove files outside the workspace (like temporary files or cache files).\nDoes not remove files in the `.git` repository of the workspace.\n\nDelete untracked nested repositories::\n\n  Remove subdirectories which contain `.git` subdirectories if this option is enabled.\n  This is implemented in command line git as `git clean -xffd`.\n  Refer to the link:https://git-scm.com/docs/git-clean[git clean manual page] for more information.\n\n[#sparse-checkout-paths]\n==== Sparse checkout paths\n\nimage:images/git-sparse-checkout-paths.png[Sparse checkout paths]\n\nSpecify the paths that you'd like to sparse checkout.\nThis may be used for saving space (Think about a reference repository).\nBe sure to use a recent version of Git, at least above 1.7.10.\n\nMultiple sparse checkout path values can be added to a single job.\n\nPath::\n\n  File or directory to be included in the checkout\n\n[source,groovy]\n----\ncheckout scmGit(\n    branches: [[name: 'master']],\n    extensions: [\n        sparseCheckout(sparseCheckoutPaths: [[path: 'src'], [path: 'Makefile']])\n    ],\n    userRemoteConfigs: [[url: 'https://github.com/jenkinsci/git-plugin.git']])\n----\n\n[#git-lfs-pull-after-checkout]\n==== Git LFS pull after checkout\n\nimage:images/git-lfs-pull-after-checkout.png[Git LFS pull after checkout]\n\nEnable https://git-lfs.github.com/[git large file support] for the workspace by pulling large files after the checkout completes.\nRequires that the controller and each agent performing an LFS checkout have installed `git lfs`.\n\n[#changelog-extensions]\n=== Changelog Extensions\n\nThe plugin can calculate the source code differences between two builds.\nChangelog extensions adapt the changelog calculations for different cases.\n\n[#calculate-changelog-against-a-specific-branch]\n==== Calculate changelog against a specific branch\n\nimage:images/git-calculate-changelog-against-a-specific-branch.png[Calculate changelog against a specific branch]\n\n'Calculate changelog against a specific branch' uses the specified branch to compute the changelog instead of computing it based on the previous build.\nThis extension can be useful for computing changes related to a known base branch, especially in environments which do not have the concept of a \"pull request\".\n\nName of repository::\n\n  Name of the repository, such as 'origin', that contains the branch.\n\nName of branch::\n\n  Name of the branch used for the changelog calculation within the named repository.\n\n[#use-commit-author-in-changelog]\n==== Use commit author in changelog\n\nimage:images/git-use-commit-author-in-changelog.png[Use commit author in changelog]\n\nThe default behavior is to use the Git commit's \"Committer\" value in build changesets.\nIf this option is selected, the git commit's \"Author\" value is used instead.\n\n[#tagging-extensions]\n=== Tagging Extensions\n\nTagging extensions allow the plugin to apply tags in the current workspace.\n\n[#create-a-tag-for-every-build]\n==== Create a tag for every build\n\nimage:images/git-create-a-tag-for-every-build.png[Create a tag for every build]\n\nCreate a tag in the workspace for every build to unambiguously mark the commit that was built.\nYou can combine this with Git publisher to push the tags to the remote repository.\n\n[#build-initiation-extensions]\n=== Build Initiation Extensions\n\nThe git plugin can start builds based on many different conditions.\nThe build initiation extensions control the conditions that start a build.\nThey can ignore notifications of a change or force a deeper evaluation of the commits when polling\n\n[#dont-trigger-a-build-on-commit-notifications]\n==== Don't trigger a build on commit notifications\n\nimage:images/git-do-not-trigger-a-build-on-commit-notifications.png[Do not trigger a build on commit notifications]\n\nIf checked, this repository will be ignored when the notifyCommit URL is accessed whether the repository matches or not.\n\n[#force-polling-using-workspace]\n==== Force polling using workspace\n\nimage:images/git-force-polling-using-workspace.png[Force polling using workspace]\n\nThe git plugin polls remotely using `ls-remote` when configured with a single branch (no wildcards!).\nWhen this extension is enabled, the polling is performed from a cloned copy of the workspace instead of using `ls-remote`.\n\nIf this option is selected, polling will use a workspace instead of using `ls-remote`.\n\nBy default, the plugin polls by executing a polling process or thread on the Jenkins controller.\nIf the Jenkins controller does not have a git installation, the administrator may \u003c\u003cenabling-jgit,enable JGit\u003e\u003e to use a pure Java git implementation for polling.\nIn addition, the administrator may need to \u003c\u003cGitPlugin-WhyNotJGit,disable command line git\u003e\u003e to prevent use of command line git on the Jenkins controller.\n\n[#polling-ignores-commits-from-certain-users]\n==== Polling ignores commits from certain users\n\nimage:images/git-polling-ignores-commits-from-certain-users.png[Polling ignores commits from certain users]\n\nThese options allow you to perform a merge to a particular branch before building.\nFor example, you could specify an integration branch to be built, and to merge to master.\nIn this scenario, on every change of integration, Jenkins will perform a merge with the master branch, and try to perform a build if the merge is successful.\nIt then may push the merge back to the remote repository if the Git Push post-build action is selected.\n\nExcluded Users::\n\n  If set and Jenkins is configured to poll for changes, Jenkins will ignore any revisions committed by users in this list when determining if a build should be triggered.\n  This can be used to exclude commits done by the build itself from triggering another build, assuming the build server commits the change with a distinct SCM user.\n  Using this behavior prevents the faster `git ls-remote` polling mechanism.\n  It forces polling to require a workspace, as if you had selected the \u003c\u003cforce-polling-using-workspace,Force polling using workspace\u003e\u003e extension.\n\n  Each exclusion uses exact string comparison and must be separated by a new line.\n  User names are only excluded if they exactly match one of the names in this list.\n\n[#polling-ignores-commits-in-certain-paths]\n==== Polling ignores commits in certain paths\n\nimage:images/git-polling-ignores-commits-in-certain-paths.png[Polling ignores commits in certain paths]\n\nIf set and Jenkins is configured to poll for changes, Jenkins will pay attention to included and/or excluded files and/or folders when determining if a build needs to be triggered.\n\nUsing this behavior will preclude the faster remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the \u003c\u003cforce-polling-using-workspace,Force polling using workspace\u003e\u003e extension as well.\nThis can be used to exclude commits done by the build itself from triggering another build, assuming the build server commits the change with a distinct SCM user.\nUsing this behavior will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace, as if you had selected the \u003c\u003cforce-polling-using-workspace,Force polling using workspace\u003e\u003e extension as well.\n\nIncluded Regions::\n\n  Each inclusion uses java regular expression pattern matching, and must be separated by a new line.\n  An empty list implies that everything is included.\n\nExcluded Regions::\n\n  Each exclusion uses java regular expression pattern matching, and must be separated by a new line.\n  An empty list excludes nothing.\n\n[#polling-ignores-commits-with-certain-messages]\n==== Polling ignores commits with certain messages\n\nimage:images/git-polling-ignores-commits-with-certain-messages.png[Polling ignores commits with certain messages]\n\nExcluded Messages::\n\n  If set and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed with message matched to the regular expression pattern when determining if a build needs to be triggered.\n  This can be used to exclude commits done by the build itself from triggering another build, assuming the build server commits the change with a distinct message.\n  You can create more complex patterns using embedded flag expressions.\n\n[#strategy-for-choosing-what-to-build]\n==== Strategy for choosing what to build\n\nimage:images/git-strategy-for-choosing-what-to-build.png[Strategy for choosing what to build]\n\nWhen you are interested in using a job to build multiple branches, you can choose how Jenkins chooses the branches to build and the order they should be built.\n\nThis extension point in Jenkins is used by many other plugins to control the job as it builds specific commits.\nWhen you activate those plugins, you may see them installing a custom build strategy.\n\nAncestry::\n\nMaximum Age of Commit::\n\n  The maximum age of a commit (in days) for it to be built.\n  This uses the GIT_COMMITTER_DATE, not GIT_AUTHOR_DATE\n\nCommit in Ancestry::\n\n  If an ancestor commit (SHA-1) is provided, only branches with this commit in their history will be built.\n\nDefault::\n\n  Build all the branches that match the branch name pattern.\n\nInverse::\n\n  Build all branches except for those which match the branch specifiers configure above.\n  This is useful, for example, when you have jobs building your master and various release branches and you want a second job which builds all new feature branches.\n  For example, branches which do not match these patterns without redundantly building master and the release branches again each time they change.\n\n[#first-build-changelog]\n==== First build changelog\n\nimage:/images/git-extension-for-first-build.png[First build changelog]\n\nThe Jenkins git plugin provides an option to trigger a Pipeline build on the first commit on a branch.\nBy default, no changelog is generated for the first build because the first build has no predecessor build for comparison.\nWhen the first build changelog option is enabled, the most recent commit will be used as the changelog of the first build.\n\n[source,groovy]\n----\ncheckout scmGit(\n    branches: [[name: 'master']],\n    extensions: [ firstBuildChangelog() ],\n    userRemoteConfigs: [[url: 'https://github.com/jenkinsci/git-plugin.git']])\n----\n\n[#merge-extensions]\n=== Merge Extensions\n\nThe git plugin can optionally merge changes from other branches into the current branch of the agent workspace.\nMerge extensions control the source branch for the merge and the options applied to the merge.\n\n[#merge-before-build]\n==== Merge before build\n\nimage:images/git-merge-before-build.png[Merge before build]\n\nThese options allow you to perform a merge to a particular branch before building.\nFor example, you could specify an integration branch to be built, and to merge to master.\nIn this scenario, on every change of integration, Jenkins will perform a merge with the master branch, and try to perform a build if the merge is successful.\nIt then may push the merge back to the remote repository if the \u003c\u003cpublisher-push-merge-results,Git Publisher post-build action\u003e\u003e is selected.\n\nName of repository::\n\n  Name of the repository, such as origin, that contains the branch. If\n  left blank, it'll default to the name of the first repository\n  configured.\n\nBranch to merge to::\n\n  The name of the branch within the named repository to merge to, such as\n  master.\n\nMerge strategy::\n\n  Merge strategy selection. Choices include:\n\n* default\n* resolve\n* recursive\n* octopus\n* ours\n* subtree\n* recursive_theirs\n\nFast-forward mode::\n\n* `--ff`: fast-forward which gracefully falls back to a merge commit when required\n* `-ff-only`: fast-forward without any fallback\n* `--no-ff`: merge commit always, even if a fast-forward would have been allowed\n\n[#custom-user-name-e-mail-address]\n==== Custom user name/e-mail address\n\nimage:images/git-custom-user-name-e-mail-address.png[Custom user name/e-mail address]\n\nuser.name::\n\n  Defines the user name value which git will assign to new commits made in the workspace.\n  If given, the environment variables `GIT_COMMITTER_NAME` and `GIT_AUTHOR_NAME` are set for builds and override values from the global settings.\n\nuser.email::\n\n  Defines the user email value which git will assign to new commits made in the workspace.\n  If given, the environment variables `GIT_COMMITTER_EMAIL` and `GIT_AUTHOR_EMAIL` are set for builds and override values from the global settings.\n\n[#deprecated-extensions]\n=== Deprecated Extensions\n\n[#custom-scm-name---deprecated]\n==== Custom SCM name - *Deprecated*\n\nUnique name for this SCM.\nWas needed when using Git within the Multi SCM plugin.\nPipeline is the robust and feature-rich way to checkout from multiple repositories in a single job.\n\n[#submodule-combinator---removed]\n==== Submodule Combinator - *Removed*\n\nAn experiment was created many years ago that attempted to create combinations of submodules within the Jenkins job.\nThe experiment was never available to Freestyle projects or other legacy projects like multi-configuration projects.\nIt was visible in Pipeline, configuration as code, and JobDSL.\n\nThe implementation of the experiment has been removed.\nDependabot and other configuration tools are better suited to evaluate submodule combinations.\n\nThere are no known uses of the submodule combinator and no open Jira issues reported against the submodule combinator.\nThose who were using submodule combinator should remain with git plugin versions prior to 4.6.0.\n\nThe submodule combinator ignores any user provided value of the following arguments to git's `checkout scm`:\n\ndoGenerateSubmoduleConfigurations::\n\n  A boolean that is now always set to `false`.\n  Submodule configurations are no longer evaluated by the git plugin.\n\nsubmoduleCfg::\n\n  A list of submodule names and branches that is now always empty.\n  Submodule configurations are no longer evaluated by the git plugin.\n\nPrevious Pipeline syntax looked like this:\n\n```groovy\ncheckout([$class: 'GitSCM',\n    branches: [[name: 'master']],\n    doGenerateSubmoduleConfigurations: false,\n    extensions: [],\n    submoduleCfg: [],\n    userRemoteConfigs: [[url: 'https://github.com/jenkinsci/git-plugin']]])\n```\n\nCurrent Pipeline Syntax looks like this:\n\n```groovy\ncheckout scmGit(\n    branches: [[name: 'master']],\n    userRemoteConfigs: [[url: 'https://github.com/jenkinsci/git-plugin']])\n```\n\n[#environment-variables]\n== Environment Variables\n\nThe git plugin assigns values to environment variables in several contexts.\nEnvironment variables are assigned in Freestyle, Pipeline, Multibranch Pipeline, and Organization Folder projects.\n\n[#branch-variables]\n=== Branch Variables\n\nGIT_BRANCH:: Name of branch being built including remote name, as in `origin/master`\nGIT_LOCAL_BRANCH:: Name of branch being built without remote name, as in `master`\n\n[#commit-variables]\n=== Commit Variables\n\nGIT_COMMIT:: SHA-1 of the commit used in this build\nGIT_PREVIOUS_COMMIT:: SHA-1 of the commit used in the preceding build of this project. If this is the first time a particular branch is being built, this variable is not set.\nGIT_PREVIOUS_SUCCESSFUL_COMMIT:: SHA-1 of the commit used in the most recent successful build of this project. If this is the first time a particular branch is being built, this variable is not set.\n\n[#system-configuration-variables]\n=== System Configuration Variables\n\nGIT_URL:: Remote URL of the first git repository in this workspace\nGIT_URL_n:: Remote URL of the additional git repositories in this workspace (if any)\nGIT_AUTHOR_EMAIL:: Author e-mail address that will be used for **new commits in this workspace**\nGIT_AUTHOR_NAME:: Author name that will be used for **new commits in this workspace**\nGIT_COMMITTER_EMAIL:: Committer e-mail address that will be used for **new commits in this workspace**\nGIT_COMMITTER_NAME:: Committer name that will be used for **new commits in this workspace**\n\n[#token-macro-variables]\n=== Token Macro Variables\n\nSome Jenkins plugins (like link:https://plugins.jenkins.io/email-ext/[email extension], link:https://plugins.jenkins.io/build-name-setter/[build name setter], and link:https://plugins.jenkins.io/description-setter/[description setter]) allow parameterized references to reformat the text of supported variables.\nVariables that support parameterized references to reformat their text are called \"token macros\".\nThe git plugin provides token macros for:\n\nGIT_REVISION:: Expands to the Git SHA1 commit ID that points to the commit that was built.\n  length:: integer length of the commit ID that should be displayed.\n  `${GIT_REVISION}` might expand to `a806ba7701bcfc9f784ccb7854c26f03e045c1d2`, while `${GIT_REVISION,length=8}` would expand to `a806ba77`.\n\nGIT_BRANCH:: Expands to the name of the branch that was built.\n  all:: boolean that expands to all branch names that point to the current commit when enabled.\n  By default, the token expands to just one of the branch names\n  fullName:: boolean that expands to the full branch name, such as `remotes/origin/master` or `origin/master`.\n  Otherwise, it expands to the short name, such as `master`.\n\nThe most common use of token macros is in Freestyle projects.\nJenkins Pipeline supports a rich set of string operations so that token macros are not generally used in Pipelines.\n\nWhen used with Pipeline, the token macro base values are generally assigned by the first checkout performed in a Pipeline.\nSubsequent checkout operations do not modify the values of the token macros in the Pipeline.\n\n[#properties]\n== Properties\n\nSome git plugin settings can only be controlled from command line properties set at Jenkins startup.\n\n[#default-timeout]\n=== Default Timeout\n\nThe default git timeout value (in minutes) can be overridden by the `org.jenkinsci.plugins.gitclient.Git.timeOut` property (see https://issues.jenkins.io/browse/JENKINS-11286[JENKINS-11286]).\nThe property should be set on the controller and on all agents to have effect (see https://issues.jenkins.io/browse/JENKINS-22547[JENKINS-22547]).\n\n[[GitPlugin-WhyNotJGit]]\n=== Disable command line git\n\nCommand line git is the reference git implementation in the git plugin and the git client plugin.\nCommand line git provides the most functionality and is the most stable implementation.\nSome installations may not want to install command line git and may want to disable the command line git implementation.\nAdministrators may disable command line git with the property `org.jenkinsci.plugins.gitclient.Git.useCLI=false`.\n\n[#allow-local-checkout]\n=== Allow local checkout\n\nCommand line git and JGit can fetch a repository using a local URL (like `file:/my/repo.git`) or a path (like `/my/repo.git`).\nlink:https://www.jenkins.io/security/advisory/2022-05-17/#SECURITY-2478[SECURITY-2478] notes that fetching from a local URL or a path creates a security vulnerability on the Jenkins controller.\nCurrent releases of the git plugin disallow fetch from a local URL and from a path.\nIf a local URL or a path is required and administrators accept the risk of disabling this security safeguard, the Java property `hudson.plugins.git.GitSCM.ALLOW_LOCAL_CHECKOUT=true` can be set from the command line that starts the Jenkins controller.\n\n[#cacheRootDir]\n=== Cache root directory\n\nMultibranch Pipelines that use the Git branch source will create cached git repositories on the Jenkins controller.\nBy default, the cached git repositories are stored in the `caches` subdirectory of the Jenkins home directory (`JENKINS_HOME`).\n\nAdministrators may want to store those git repositories in another location for better performance or to exclude them from backups.\nFor example, they might choose to place the cache directories in `/var/cache/jenkins`.\n\nThe default git cache directory location can be overridden by setting the property `jenkins.plugins.git.AbstractGitSCMSource.cacheRootDir=/var/cache/jenkins`.\n\n[#ignoreTagDiscoveryTrait]\n=== Ignore tag discovery trait\n\nMultibranch Pipelines that use the Git branch source prior to Git plugin 5.8.0 always fetch tags from the remote repository, whether or not the tag discovery trait is set.\nThat bug is fixed in Git plugin 5.8.0 and later.\n\nAdministrators that depend on the old (buggy) behavior can set the property `jenkins.plugins.git.GitSCMSource.IGNORE_TAG_DISCOVERY=true`.\nWhen administrators detect that their multibranch Pipelines depend on that bug, they should add the tag discovery trait to the multibranch Pipeline definition.\n\n[#git-publisher]\n== Git Publisher\n\nThe Jenkins git plugin provides a \"git publisher\" as a post-build action.\nThe git publisher can push commits or tags from the workspace of a Freestyle project to the remote repository.\n\nThe git publisher is **only available** for Freestyle projects.\nIt is **not available** for Pipeline, Multibranch Pipeline, Organization Folder, or any other job type other than Freestyle.\n\n[#git-publisher-options]\n=== Git Publisher Options\n\nThe git publisher behaviors are controlled by options that can be configured as part of the Jenkins job.\nOptions include;\n\nPush Only If Build Succeeds::\n\n  Only push changes from the workspace to the remote repository if the build succeeds.\n  If the build status is unstable, failed, or canceled, the changes from the workspace will not be pushed.\n\n[[publisher-push-merge-results]]\nMerge Results::\n\n  If pre-build merging is configured through one of the \u003c\u003cmerge-extensions,merge extensions\u003e\u003e, then enabling this checkbox will push the merge to the remote repository.\n\n[[publisher-tag-force-push]]\nForce Push::\n\n  Git refuses to replace a remote commit with a different commit.\n  This prevents accidental overwrite of new commits on the remote repository.\n  However, there may be times when overwriting commits on the remote repository is acceptable and even desired.\n  If the commits from the local workspace should overwrite commits on the remote repository, enable this option.\n  It will request that the remote repository destroy history and replace it with history from the workspace.\n\n[#git-publisher-tags-options]\n==== Git publisher tags options\n\nThe git publisher can push tags from the workspace to the remote repository.\nOptions in this section will allow the plugin to create a new tag.\nOptions will also allow the plugin to update an existing tag, though the link:https://git-scm.com/docs/git-tag#_on_re_tagging[git documentation] **strongly advises** against updating tags.\n\nTag to push::\n\n  Name of the tag to be pushed from the local workspace to the remote repository.\n  The name may include link:https://jenkins.io/doc/book/pipeline/jenkinsfile/#using-environment-variables[Jenkins environment variables] or may be a fixed string.\n  For example, the tag to push might be `$BUILD_TAG`, `my-tag-$BUILD_NUMBER`, `build-$BUILD_NUMBER-from-$NODE_NAME`, or `a-very-specific-string-that-will-be-used-once`.\n\nTag message::\n\n  If the option is selected to create a tag or update a tag, then this message will be associated with the tag that is created.\n  The message will expand references to link:https://jenkins.io/doc/book/pipeline/jenkinsfile/#using-environment-variables[Jenkins environment variables].\n  For example, the message `Build $BUILD_NUMBER tagged on $NODE_NAME` will use the message `Build 1 tagged on special-agent` if build 1 of the job runs on an agent named 'special-agent'.\n\nCreate new tag::\n\n  Create a new tag in the workspace.\n  The git publisher will fail the job if the tag already exists.\n\nUpdate new tag::\n\n  Modify existing tag in the workspace so that it points to the most recent commit.\n  Many git repository hosting services will reject attempts to push a tag which has been modified to point to a different commit than its original commit.\n  Refer to \u003c\u003cpublisher-tag-force-push,force push\u003e\u003e for an option which may force the remote repository to accept a modified tag.\n  The link:https://git-scm.com/docs/git-tag#_on_re_tagging[git documentation] **strongly advises against updating tags**.\n\nTag remote name::\n\n  Git uses the 'remote name' as a short string replacement for the full URL of the remote repository.\n  This option defines which remote should receive the push.\n  This is typically `origin`, though it could be any one of the remote names defined when the plugin performs the checkout.\n\n[#git-publisher-branches-options]\n==== Git publisher branches options\n\nThe git publisher can push branches from the workspace to the remote repository.\nOptions in this section will allow the plugin to push the contents of a local branch to the remote repository.\n\nBranch to push::\n\n  The name of the remote branch that will receive the latest commits from the agent workspace.\n  This is usually the same branch that was used for the checkout\n\nTarget remote name::\n\n  The short name of the remote that will receive the latest commits from the agent workspace.\n  Usually this is `origin`.\n  It needs to be a short name that is defined in the agent workspace, either through the initial checkout or through later configuration.\n\nRebase before push::\n\n  Some Jenkins jobs may be blocked from pushing changes to the remote repository because the remote repository has received new commits since the start of the job.\n  This may happen with projects that receive many commits or with projects that have long running jobs.\n  The `Rebase before push` option fetches the most recent commits from the remote repository, applies local changes over the most recent commits, then pushes the result.\n  The plugin uses `git rebase` to apply the local changes over the most recent remote changes.\n+\nBecause `Rebase before push` is modifying the commits in the agent workspace **after the job has completed**, it is creating a configuration of commits that has **not been evaluated by any Jenkins job**.\nThe commits in the local workspace have been evaluated by the job.\nThe most recent commits from the remote repository have not been evaluated by the job.\nUsers may find that the risk of pushing an untested configuration is less than the risk of delaying the visibility of the changes which have been evaluated by the job.\n\n[#combining-repositories]\n== Combining repositories\n\nA single reference repository may contain commits from multiple repositories.\nFor example, if a repository named `parent` includes references to submodules `child-1` and `child-2`, a reference repository could be created to cache commits from all three repositories using the commands:\n\n....\n$ mkdir multirepository-cache.git\n$ cd  multirepository-cache.git\n$ git init --bare\n$ git remote add parent https://github.com/jenkinsci/git-plugin\n$ git remote add child-1 https://github.com/jenkinsci/git-client-plugin\n$ git remote add child-2 https://github.com/jenkinsci/platformlabeler-plugin\n$ git fetch --all\n....\n\nThose commands create a single bare repository with the current commits from all three repositories.\nIf that reference repository is used in the advanced clone options link:#clone-reference-repository-path[clone reference repository], it will reduce data transfer and disc use for the parent repository.\nIf that reference repository is used in the submodule options link:#submodule-reference-repository-path[clone reference repository], it will reduce data transfer and disc use for the submodule repositories.\n\n[#bug-reports]\n== Bug Reports\n\nReport issues and enhancements in the link:https://www.jenkins.io/participate/report-issue/redirect/#15543[Jenkins issue tracker].\n\n[#contributing-to-the-plugin]\n== Contributing to the Plugin\n\nRefer to link:CONTRIBUTING.adoc#contributing-to-the-git-plugin[contributing to the plugin] for contribution guidelines.\n\n== Remove Git Plugin BuildsByBranch BuildData Script\n\nThe git plugin has an issue (link:https://issues.jenkins.io/browse/JENKINS-19022[JENKINS-19022]) that sometimes causes excessive memory use and disc use in the build history of a job.\nThe problem occurs because in some cases the git plugin copies the git build data from previous builds to the most recent build, even though the git build data from the previous build is not used in the most recent build.\nThe issue can be especially challenging when a job retains a very large number of historical builds or when a job builds a wide range of commits during its history.\n\nMultiple attempts to resolve the core issue without breaking compatibility have been unsuccessful.\nA workaround is provided below that will remove the git build data from the build records.\nThe workaround is a system groovy script that needs to be run from the Jenkins Administrator's Script Console (as in \\https://jenkins.example.com/script ).\nAdministrator permission is required to run system groovy scripts.\n\nThis script removes the static list of BuildsByBranch that is stored for each build by the Git Plugin.\n\n[source,groovy]\n----\nimport hudson.matrix.*\nimport hudson.model.*\n\nhudsonInstance = hudson.model.Hudson.instance\njobNames = hudsonInstance.getJobNames()\nallItems = []\nfor (name in jobNames) {\n  allItems += hudsonInstance.getItemByFullName(name)\n}\n\n// Iterate over all jobs and find the ones that have a hudson.plugins.git.util.BuildData\n// as an action.\n//\n// We then clean it by removing the useless array action.buildsByBranchName\n//\n\nfor (job in allItems) {\n  println(\"job: \" + job.name);\n  def counter = 0;\n  for (build in job.getBuilds()) {\n    // It is possible for a build to have multiple BuildData actions\n    // since we can use the Multiple SCM plugin.\n    def gitActions = build.getActions(hudson.plugins.git.util.BuildData.class)\n    if (gitActions != null) {\n      for (action in gitActions) {\n        action.buildsByBranchName = new HashMap\u003cString, Build\u003e();\n        hudson.plugins.git.Revision r = action.getLastBuiltRevision();\n        if (r != null) {\n          for (branch in r.getBranches()) {\n            action.buildsByBranchName.put(branch.getName(), action.lastBuild)\n          }\n        }\n        build.actions.remove(action)\n        build.actions.add(action)\n        build.save();\n        counter++;\n      }\n    }\n    if (job instanceof MatrixProject) {\n      def runcounter = 0;\n      for (run in build.getRuns()) {\n        gitActions = run.getActions(hudson.plugins.git.util.BuildData.class)\n        if (gitActions != null) {\n          for (action in gitActions) {\n            action.buildsByBranchName = new HashMap\u003cString, Build\u003e();\n            hudson.plugins.git.Revision r = action.getLastBuiltRevision();\n            if (r != null) {\n              for (branch in r.getBranches()) {\n                action.buildsByBranchName.put(branch.getName(), action.lastBuild)\n              }\n            }\n            run.actions.remove(action)\n            run.actions.add(action)\n            run.save();\n            runcounter++;\n          }\n        }\n      }\n      if (runcounter \u003e 0) {\n        println(\" --\u003e\u003e cleaned: \" + runcounter + \" runs\");\n      }\n    }\n  }\n  if (counter \u003e 0) {\n    println(\"-- cleaned: \" + counter + \" builds\");\n  }\n}\n----\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjenkinsci%2Fgit-plugin","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjenkinsci%2Fgit-plugin","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjenkinsci%2Fgit-plugin/lists"}