Skip to main content
supports Git-based version control for most of your application configurations, bringing enterprise-grade change management to your data integration platform. This feature enables teams to track configuration changes with full audit trails, maintain separate environments for testing and production, and quickly recover from issues by rolling back to known good states. With Git integration, team members can collaborate on configurations with proper attribution and change history, ensuring compliance requirements are met while reducing the risk of configuration errors. Organizations can apply the same rigorous version control practices to their configurations that they already use for application code. supports Git version control with a Remote repository connected to a hosted Git platform (such as GitHub, GitLab, Azure DevOps, or Bitbucket). Self-hosted installations also support a Local repository that runs directly on the server, without requiring any external Git infrastructure. All files (such as *.cfg, XML, JSON, and binaries) are tracked, unless you have manually added them to your .gitignore file. See Architecture for more details on the file types that are tracked.
The vault and its contents, as well as users and roles, are not version-controlled. To avoid versioning sensitive values like tokens, usernames, and passwords, recommends that you store all sensitive values in the vault and reference the vault items in connectors where the sensitive values are required.

​
Installation and Configuration

​
Prerequisites

Before you can use the version control features, you must install Git on all environments, including development and production. If you are using a remote repository, you must also create it before configuring version control. supports all major Git platforms, including GitHub, GitLab, Azure DevOps, and Bitbucket. If you are using a local repository, no remote setup is required.

​
Installing Git

Windows
  1. Download the Git installer from git-scm.com/download/win.
  2. Run the installer and follow the installation wizard using your preferred settings.
  3. Verify the installation by opening a command prompt or PowerShell and running:
You should see output showing the installed Git version.
Linux Debian/Ubuntu
Run the following:
Linux Fedora/RHEL/CentOS
Run the following:
Run this command to verify the installation:
Once Git is installed and verified, you can begin to use the version control features.

​
Configure Version Control

Navigate to Settings > Advanced > Git Version Control to set up version control. See Git Version Control Settings for the complete settings reference. When you click Configure, you first choose a Configuration Type:
  • Remote: connects to a hosted Git repository. This enables push, pull, and team collaboration across multiple environments.
  • Local: creates a standalone Git repository directly on the server. No remote URL or credentials are required. This is the fastest way to get started with version control.
For remote repositories, supply the repository URL and authentication credentials. Creating the remote repository itself is beyond the scope of this documentation; consult your Git platform’s documentation. For example, when using HTTPS authentication with GitHub, you must use a Personal Access Token (PAT) instead of a password.

​
Development Environments

This section applies to remote repositories only. Local repositories do not have a remote to sync with, so separate development environments are not required.
When you use version control with in a shared production environment, recommends setting up individual development environments for each team member. This provides users with the best experience and avoids conflicts that can occur when multiple users try to push and pull changes simultaneously in a shared environment. Working directly in a shared production environment with version control can lead to:
  • Merge conflicts when multiple users make changes at the same time
  • Poor user experience due to competing version control operations
By using development environments, each team member can work independently, test their changes locally, and push completed work to the repository without interfering with others or disrupting production operations. Follow these steps to configure a local development environment that mirrors your production instance:
  1. Export the data encryption key from production (see Understanding Data Encryption Keys and Master Keys for more information on key usage)
    1. In your production environment, use your API key to call the Admin API exportDataEncryptionKey endpoint. Use the passphrase parameter to create the passphrase that will be used when you import the key to the development environment.
    2. Save the response because you need this data encryption key for your development environment.
  2. Export the vault from your production environment:
    1. Use the UI
      1. Navigate to Settings > Advanced > Migration > Export
      2. Select Custom Export and create a Password, then click Next
      3. On the Settings tab, only check Vault
      4. Click Export to perform the export and download the file
    2. Use the Admin API export endpoint with the vault option enabled
  3. Install in your development environment (if it is not already installed)
    1. Install on your development machine
    2. Complete the initial setup and create your first user account
    3. Install your development license
    4. Create an API key for API access
  4. Import the data encryption key to development: In your development environment, use your API key to call the Admin API importDataEncryptionKey endpoint with the same passphrase you used when you exported the key from production. This ensures that your development environment uses the same data encryption key and can decrypt the vault contents.
  5. Import the vault to development
    1. Use the UI
      1. Navigate to Settings > Advanced > Migration > Import
      2. Upload the vault file you exported earlier
      3. Complete the import process
    2. Use the Admin API import endpoint to upload and import the vault file.
  6. Pull the remote repository to sync your development environment with the production configuration
    1. Use the UI
      1. Install Git by following the instructions in Prerequisites
      2. Navigate to Settings > Advanced > Git Version Control
      3. Configure your remote repository connection (see Git Version Control Settings for instructions)
      4. Pull the latest changes from the remote repository
    2. Use standard Git commands to configure the repository connection on your local machine
Once your development environment is configured, you can:
  • Make and test changes locally without affecting production
  • Commit changes to your local repository
  • Push completed work to the remote repository
  • Pull updates made by other team members
  • Follow standard Git workflows (such as branches and pull requests) for collaborative development
Your production environment can now pull approved changes from the remote repository on a controlled schedule.

​
Version Control Operations

‘s Git integration provides essential version control operations that allow you to manage configuration changes, synchronize with remote repositories, and maintain multiple development branches. These operations follow standard Git workflows while being tailored specifically for ‘s configuration management needs. Once version control is implemented on your environments, the standard footer becomes a status bar that displays Git metrics and actions such as the number of local files changed, the number of remote commits, and the current branch. Git version control footer toolbar

​
Permissions

Version control features are visible to all users, not just administrators. Role-based access control permissions determine what Git actions you can perform.
  • Read-only users can view status and history only
  • Write users can commit, push, pull, and create branches

​
Commit and Push

Commit captures all configuration changes in as a single atomic unit and saves them to your local Git repository. When you commit, automatically records your username as the author and timestamps the change, ensuring full traceability of who made what changes, and when. A commit message is required to document the purpose of your changes, and you must have Write permissions to perform commits. Push synchronizes your local commits to the remote Git repository, making your changes available to other team members and backup systems. If the remote branch contains newer changes that you haven’t pulled yet, the push operation fails with an error message and suggestions of what to do next. This prevents overwriting other users’ work and ensures proper merge handling. For remote repositories, commit and push are handled in a single action. See Commit and Push New Changes for details. For local repositories, there is no push step; the toolbar shows Commit instead of Commit and Push.

​
Pull

Pull is available for remote repositories only. Local repositories do not have a remote to pull from.
Pull retrieves the latest changes from the remote Git repository and updates your local configuration. Before pulling, you must commit or discard any uncommitted local changes; the operation fails if uncommitted changes are detected. If there are merge conflicts between your local version and the remote version, the pull fails with a message directing you to resolve the conflict externally using Git tools (see Manage Commit and Pull Conflicts) for details. Pull operations can be initiated from the Git toolbar. See Pull Changes for details.

​
Branch

Branch management allows you to maintain separate configuration versions for different purposes, such as development, testing, and production environments. Use the branch dropdown in the toolbar to switch between branches, create new ones, or delete stale ones. When creating a new branch, specify the branch name and select which branch to create it from (the default is to use your current branch). This enables you to experiment with configuration changes without affecting your main environment. See Create Branches and Delete Branches for details.

​
Logging

All version control changes are captured in the Audit logs section of the Activity page. You can download logs from that page as necessary. Audit logs for version control changes

​
History Viewer

Once version control is enabled, a Commits History tab appears on the Activity page. It shows the complete commit history and provides details such as the commit hash, commit message, author, date and time, and a list of the files that were changed in each commit. You can search and filter the content on this tab. Commit history tab on the Activity page Click a Commit hash to open the Commit Details page. It opens to a File Changes tab which displays a diff view of the files in the commit so you can see exactly what has changed. Click the Details tab to see the author, commit message and timestamp. Commit details with file diff view The diff displays the old and new values of all changed settings, with the following notes:
  • Passwords and secrets are masked
  • Vault references are prefixed with a key symbol
The Go To Resource link on the File Changes tab takes you to the part of where the file was changed. For example, if you are viewing the diff of a MySQL connector, clicking the link takes you to that MySQL connector.

​
Version Control Workflows Examples

The following examples demonstrate common version control scenarios encountered when working with ‘s Git integration. These workflows cover the essential operations: pulling updates from remote repositories, creating and deleting branches, committing and pushing changes, restoring changes, resolving conflicts when local and remote changes diverge, and discarding unwanted modifications.

​
Pull Changes

This workflow applies to remote repositories only.
You can pull changes from remote in several ways:
  • Click Pull on the toolbar to pull the commits without reviewing them
  • Click the number of commits on the toolbar to open the Pull Remote Commits preview Pull remote commits preview
  • Navigate to the Commits History tab on the Activity page and click the link to the number of remote commits on the left or the Pull button on the right to open the Pull Remote Commits preview
The Pull Remote Commits preview lists all commits that are ready to be pulled. Click a commit to see its details, then hover over the number of files to see which files are included in the commit. To complete the task, click Pull Commits. Pull remote commits confirmation dialog

​
Create Branches

To create a new branch, click the branch icon on the toolbar (you can also switch between branches here). Branch switcher on the toolbar Click Add Branch and give your branch a Name. Choose which branch to copy from, then click Add. Add branch dialog

​
Delete Branches

To delete a branch, click the branch icon on the toolbar. Hover over the branch you want to delete and click the trashcan icon. Delete branch dialog

​
Commit and Push New Changes

When you are making changes in , the toolbar shows the total number of files that have been changed: Git toolbar showing number of changed files Click Commit & Push to open the Local File Changes pane. It shows details about the files that you have changed. You must supply a commit message before you can commit and push your changes to remote.
For remote repositories, commit and push happen as a single step; you do not commit locally and then push separately. For local repositories, only Commit is available since there is no remote to push to.
Local file changes pane with commit message field After you commit and push the changes, a confirmation message in the toolbar lets you know the result of your action.

​
Restore Changes from a Previous Revision

To restore resources to their previous state, navigate to the Commits History tab on the Activity page. Click the ellipses to the right of the Files Changed column, then click Restore. Review the diff between the current state and the proposed restore point state, then click Next. Be aware that if you proceed with the restore, any uncommitted changes in those files are permanently lost. Click Restore Resources to complete the task.

​
Manage Commit and Pull Conflicts

This section applies to remote repositories only. Commit conflicts do not occur with local repositories because there is no remote branch to diverge from.
Conflicts can arise when you have local changes to push and there are also remote changes to pull. The toolbar reflects the conflicts, and provides suggestions on how to proceed. The same error messages also appear on the Commit and Pull Remote Commits preview pages. Commit and pull conflict message in toolbar One option is to manage the conflicts manually, and the other is to commit the current changes to a different branch, which then allows you to pull remote changes to the current branch. Click Please commit to a new branch to open a page where you can select a different branch to commit to. Once you select (or create) the new branch, you can push your changes using Commit & Push Changes.

​
Discard Changes

To discard your current changes, click the trashcan icon in the toolbar. This opens a Discard Changes pane, where you can select exactly which changes to discard. Click Next, confirm that your selections are correct, then click Discard Changes. Once complete, a confirmation message appears and the number of changes in the toolbar is reduced by the number of changes that were discarded.

​
Migrate from a Local to a Remote Repository

If you start with a local repository and later want to connect to a remote server while preserving your commit history, follow these steps:
  1. Create the remote repository: set up a new, empty repository on your Git platform (such as GitHub, GitLab, or Bitbucket).
  2. Add the remote via the command line: on the server, navigate to the data directory and run:
  3. Update the configuration: navigate to Settings > Advanced > Git Version Control. recognizes the remote you added in Step 2, but push and pull operations are not fully functional until you edit and add your Username and Password/Token credentials. Once your Status shows Connected, all previous commits from the Local repository are visible in the remote.