on:  Static websites
Search
List of notes
Published: August 2025
This article is part of a series on: Configuring Azure pipelines.
  1. Publish to a static web app from a git repository
  2. Running custom tools
  3. Ubuntu or Windows revisited
  4. Use git in pipelines
  5. Scheduling pipelines
  6. Pipeline notifications

Use git in pipelines

By default a pipeline takes its content from a clone of a branch of the git repository. Once the pipeline has completed, the clone is discarded. Sometimes the creation of the website updates content or derived files, e.g., a list of all external resources the website links to, and the changes should be kept. Or you want to push pipeline results to another branch or even repository. How to use git within a pipeline?

Authorisation

When using git in a pipeline, git is executed by an Azure DevOps build account. If the git repository is not hosted by Azure DevOps, you'll have to use a PAT or username/password to get access to the git repository. For Azure DevOps git repositories there is a better way: register the build account as contributor to the git repository.

  • Go to the project in Azure DevOps that owns the git repository.
  • Go to Project settings, then to Repositories.
  • Go to the Security overview to authorise the build account for all repositories in the project. Otherwise select the repository first, then go to its Security overview.
  • In the search box for users and groups, search for the build account and select it. Its name is: (name of the project that owns the pipeline) + “Build Service”.
  • Set Contribute to Allow (and other permissions as needed, e.g., Create branch or Create tag).

Git in the pipeline

the regular git command is available in the pipeline and can be run via script, e.g.:

  steps:
  - checkout: self
    persistCredentials: true
    fetchDepth: 0

 # ...other steps...
        
  - script: |
        git config user.name "...name..."
        git config user.email "...e-mail address..."
        git add --all
        git commit -m "Updating artefacts after website build."
        git push origin ...branch name...

A few remarks:

  • persistCredentials: true is required if the build account is authorised to access the git repository. This makes it possible to work with Azure DevOps git repositories without storing credentials as part of the pipeline. For other git repositories you have to use the git command to configure the credentials.
  • fetchDepth: 0 is required if the git commands for this repository require commit histories, e.g., if merges and pushes are involved. Otherwise branches in the git repository are checked out with a depth of 1, and after a commit (like in the example) the clone only remembers the last commit. A merge of two branches would fail, as the two last commits are unrelated (because the history is missing) and git aborts the merge. A push to a branch name would fail, as it is not known relative to what previous commit the push must be done.
  • As per default git behaviour, the user.name and user.email must be assigned but are unrelated to the account that actually executed the git commands.