Breadcrumbs

Use Git versioning for flows and subflows

Git versioning stores Flow and Subflow versions in a Git repository. Leapwork Flow supports GitHub, Bitbucket, and Azure DevOps as Git providers.

When you enable Git versioning for a team, new Flow and Subflow versions are queued for upload to the team’s mapped repository. You can view synchronization status, compare versions, preview historical versions, and restore a prior version when the Git revision and repository access are available.

Git versioning applies to Flows and Subflows. It does not apply to other asset types.

How Git versioning works

A team mapping connects one Leapwork team to one Git repository. Use a separate repository for each team that uses Git versioning.

Leapwork uses these credentials:

Credential

Purpose

Connection PAT

Tests the Git connection and lists repositories available to select.

Repository PAT

Validates the mapped repository and runs migration. It can also be used as a shared fallback when Override User PAT is enabled.

User PAT

Lets an individual user perform Git actions with their own Git identity.

By default, each user who saves, compares, previews, or restores Git-backed content needs a User PAT with the required repository access. An administrator can enable Override User PAT to use the Repository PAT as a fallback when a User PAT is unavailable.

Before you begin

  • Choose a Git provider and repository for the team.

  • Confirm that the Controller can reach the provider over HTTPS.

  • Create and test the required Git connection and tokens.

  • Confirm that contributors have the repository access needed to upload versions.

  • Use a private repository when Flow or Subflow versions contain sensitive automation details.

If the team has existing Flow or Subflow version history, migrate it before enabling the team mapping. During migration, users must not create, save, import, or edit the team’s Flows or Subflows. They should also avoid preview runs.

Create a Git connection

  1. Go to Settings > Connections.

  2. Select Add and set Type to Git Connection.

  3. Select GitHub, Bitbucket, or Azure DevOps from Version Control Provider.

  4. Enter the provider’s Git API URL.

  5. Enter the Connection PAT.

  6. Select Test connection. If the test succeeds, save the connection.

For provider-specific setup, see the GitHub, Azure DevOps, and Bitbucket Cloud setup articles.

Map a team to a repository

  1. Go to Settings > Git Connections.

  2. Select Add Team Mapping.

  3. Select the Team, Git Connection, and Repository.

  4. Enter the Repository PAT.

  5. Choose whether to enable Override User PAT.

  6. Save the mapping.

The mapping starts disabled. If the team has existing version history, run migration before enabling it. If there is no history to migrate, the migration status is Not Applicable and you can enable the mapping without running migration.

A repository appearing in the selection list does not confirm that the Repository PAT or User PAT has sufficient access. Check the selected repository and token permissions before saving the mapping.

Migrate existing versions

  1. Go to Settings > Git Connections.

  2. Select Run migration for the team mapping.

  3. Choose whether to migrate only the latest eligible version or up to the 10 most recent eligible versions of each Flow and Subflow.

  4. Select Continue and wait for the migration status to complete.

Leapwork may also migrate versions required by frozen run lists, even if that exceeds the selected number. Versions are queued in chronological order.

During migration, do not run preview runs or create, save, import, or edit the team’s Flows and Subflows. Migration runs in the mapped team’s context, so you may need to switch to that team before starting or retrying it.

Save and synchronize versions

Save Flows and Subflows as usual. Leapwork creates the version and queues it for upload to the mapped repository. Check the Git Sync column in Version History to confirm the upload status.

If your team uses User PATs, add your token in Settings > Git Connections under Git User Personal Access Token.

Compare versions

  1. Open Version History for a Flow or Subflow.

  2. Select one version and choose Compare with Latest, or select two versions and choose Compare.

  3. Review the changes side by side.

The comparison highlights added lines in green and removed lines in red. You can move between changes or switch to the full JSON view. You can compare up to two versions at a time.

Git comparison requires uploaded revisions and repository access through a User PAT or an available Repository PAT fallback.

Preview or restore a version

You can preview or restore an uploaded historical version from Version History or the comparison view when the revision and Git access are available.

Restoring a version does not overwrite the current version or delete the historical commit. Leapwork creates a new version with the selected historical content and queues it for synchronization.

Readers cannot restore versions. Administrators and Contributors need the normal edit permission for the asset.

Limitations

  • Migration includes up to 10 eligible versions per Flow or Subflow, excluding frozen revisions. Frozen run lists may require additional versions.

  • Archived versions cannot be recovered after migration and enabling Git versioning.

  • Preview-run reporting is lost after Git migration.

  • Preview, comparison, restore, and historical report rendering depend on the relevant Git revision being available and the user having repository access.

  • Leapwork does not automatically recover revisions that have a Git commit ID if the revision data is missing.