> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arc.cdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Git Version Control

> How to use Git-based version control for CData Arc configuration management, including installation, setup, and workflow examples.

CData Arc 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 Arc 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 Arc configurations that they already use for application code.

Arc 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 Arc server, without requiring any external Git infrastructure.

By default, a single **Global** repository covers the entire Arc instance. You can also give an individual workspace its own separate repository. See [Global and Workspace Repositories](#global-and-workspace-repositories) for details.

> [!NOTE]
>
> Arc tracks your configuration files (such as `*.cfg`, XML, JSON, and binaries), with two exceptions: the [vault](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/global-settings-vault.md) and its contents, and [users and roles](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/user-roles.md). To avoid versioning sensitive values like tokens, usernames, and passwords, CData recommends that you store *all* sensitive values in the vault and reference the vault items in connectors where the sensitive values are required. See [Architecture](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/architecture.md) for a complete list of tracked file types. When a workspace has its own repository, that workspace's files are tracked in the workspace repository instead of the global repository.
>
> To exclude files from version control, add entries to a `.gitignore` file in the root of your Arc [Application Directory](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/glossary.md). To exclude a file or pattern, add it on a new line in `.gitignore`. Common candidates for exclusion include environment-specific configuration files that differ across deployments and large binary files that would inflate repository size. Keep in mind that excluded files are never committed, pushed, pulled, or restored, so you must manage them separately in each environment.

## Installation and Configuration

### Prerequisites

Before you can use the version control features, you must install Git on all Arc environments, including development and production.

If you are using a remote repository, you must also create it before configuring version control. Arc 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](https://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:

   ```
   git --version
   ```

You should see output showing the installed Git version.

##### Linux Debian/Ubuntu

Run the following:

```
sudo apt-get update
sudo apt-get install git
```

##### Linux Fedora/RHEL/CentOS

Run the following:

```
sudo dnf install git
```

Run this command to verify the installation:

```
git --version
```

Once Git is installed and verified, you can begin to use the Arc version control features.

### Configure Version Control

Version control can be configured at two levels: for the application as a whole (the global repository) and, optionally, for individual workspaces. See [Global and Workspace Repositories](#global-and-workspace-repositories) to understand how the two relate.

#### Configure the Global Repository

Navigate to **Settings > Advanced > Git Version Control** to set up version control. See [Git Version Control Settings](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/git-version-control-settings.md) for details.

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 Arc environments.
* **Local**: creates a standalone Git repository directly on the Arc 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.

#### Configure a Workspace Repository

To version an individual [workspace](https://docs.arc.cdata.com/26.4/self-hosted/en/flows/workspaces.md) in its own repository:

1. Open the workspace, then click **Settings** in the ellipsis menu. Click the **Git Version Control** tab.

2. Toggle on the **Enable Git Version Control** switch. If the global repository is set up, a warning explains that enabling version control for the workspace removes it from the global repository, so it is tracked only in the repository you configure.

   ![Workspace settings Git Version Control tab with version control enabled](https://docs.arc.cdata.com/26.4/images/version_control_workspace_settings_enabled.png)

3. Configure the repository. The fields are the same as those for the application-level repository; see [Git Version Control Settings](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/git-version-control-settings.md#workspace-git-version-control-settings) for details.

   Select a **Configuration Type**:

   * **Remote**: connects to a hosted Git repository. Provide the repository URL and authentication credentials.
   * **Local**: creates a standalone Git repository on the Arc server. No remote URL or credentials are required.

   For a remote repository, provide the repository URL and authentication credentials.

4. Click **Save**.

> [!NOTE]
>
> Workspace repositories follow a few rules, such as a restriction on the **Default** workspace. See [Global and Workspace Repositories](#global-and-workspace-repositories) for details.
>
> You can convert a workspace repository between Local and Remote (see [Migrate from a Local to a Remote Repository](#migrate-from-a-local-to-a-remote-repository) and [Convert a Remote Repository to a Local Repository](#convert-a-remote-repository-to-a-local-repository)).
>
> You can change the remote URL after you save the configuration (see [Edit the Remote URL](#edit-the-remote-url)).

## Global and Workspace Repositories

Arc supports two kinds of repository:

* **Global**: the application-level repository that you configure under **Settings > Advanced > Git Version Control**. By default, it tracks the configuration for the entire instance, including every workspace.
* **Workspace**: an optional repository that versions a single workspace, separate from the global repository.

A repository that has no remote configured is labeled **Local** in the Arc interface, regardless of whether it is the global repository or a workspace repository.

Keep the following in mind when you use workspace repositories:

* If the global repository is set up, enabling a workspace repository moves the workspace out of the global repository. After you enable it, the workspace is tracked only in its configured repository.
* Shared resources stay in the global repository. Connections, certificates, and profiles that a workspace uses remain in the global repository. A workspace repository is therefore not a self-contained backup of everything that the workspace needs.
* Workspace repositories are independent of the global repository. You can enable a workspace repository whether or not you have set up a global repository.
* The **Default** workspace cannot have its own repository. Its **Git Version Control** tab shows the message *A separate Git repository is not available for the Default workspace.*

### One Repository at a Time

Every version control action applies to exactly one repository: the repository you currently have selected. Commit, push, pull, branch, discard, restore, and status all apply to the selected repository and nothing else. No action spans multiple repositories.

* An action that you start from a row in the repository list stays with that row's repository, even if the active workspace changes while the action runs.
* Progress, errors, and counts are tracked separately for each repository, so a failure in one repository does not block work in another.

Which repository is selected by default depends on where you are in Arc. On the **Flows** page, the selection follows the workspace that you are working in. Everywhere else, the selection is the global repository. You can always change the selection (see [Select a Repository](#select-a-repository)).

## Development Environments

> [!NOTE]
>
> 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 Arc in a shared production environment, CData 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 Arc instance:

1. Export the data encryption key from production (see [Understanding Data Encryption Keys and Master Keys](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/installation/custom-master-key.md#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](https://docs.arc.cdata.com/26.4/self-hosted/en/admin-api/admin-api-actions.md) 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](https://docs.arc.cdata.com/26.4/self-hosted/en/admin-api/admin-api-actions.md) endpoint with the vault option enabled

3. Install Arc in your development environment (if it is not already installed)

   1. Install Arc on your development machine
   2. Complete the initial setup and create your first [user account](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/users.md)
   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](https://docs.arc.cdata.com/26.4/self-hosted/en/admin-api/admin-api-actions.md) 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](https://docs.arc.cdata.com/26.4/self-hosted/en/admin-api/admin-api-actions.md) endpoint to upload and import the vault file.

6. [Pull](#pull-changes) the remote repository to sync your development environment with the production configuration. If any workspaces in production have their own repositories, configure and pull each of those repositories as well. Shared resources such as connections, certificates, and profiles remain in the global repository, so you must pull the global repository too.

   1. Use the UI
      1. Install Git by following the instructions in [Prerequisites](#prerequisites)
      2. Navigate to **Settings > Advanced > Git Version Control**
      3. Configure your remote repository connection (see [Git Version Control Settings](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/git-version-control-settings.md) 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

Arc'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 Arc's configuration management needs.

Once version control is implemented on your environments, the standard Arc footer becomes a status bar that displays Git metrics and actions such as the number of local files changed, the number of remote commits, the selected repository, and the current branch. All of these metrics and actions apply to the selected repository (see [One Repository at a Time](#one-repository-at-a-time)).

![Git version control footer toolbar showing the selected repository](https://mintcdn.com/cdata-arc/d_uxoDpYg8BiVilE/26.4/images/version_control_footer_toolbar.png?fit=max\&auto=format\&n=d_uxoDpYg8BiVilE\&q=85\&s=d59c1b1cf3d5ea75acdc08db5941353f)

### Permissions

Version control is restricted to administrators. Only users with the [Admin role](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/user-roles.md#admin-role) can use version control features, including viewing version control logs, for both the global repository and workspace repositories. The Version Control options are hidden in the UI for all other users.

### Commit and Push

*Commit* captures all configuration changes in the selected repository as a single atomic unit and saves them to that repository. When you commit, Arc automatically records your Arc 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.

*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](#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

> [!NOTE]
>
> Pull is available for remote repositories only. Local repositories do not have a remote to pull from.

*Pull* retrieves the latest changes from the selected repository's remote and updates your local Arc configuration. Arc does not pull automatically in the background. 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](#manage-commit-and-pull-conflicts)) for details. Pull operations can be initiated from the Git toolbar. See [Pull Changes](#pull-changes) for details.

### Select a Repository

When more than one repository is initialized, the toolbar includes a searchable repository list. Use it to see the state of every repository and to choose which one is selected.

![Repository list showing the global repository and a workspace repository](https://mintcdn.com/cdata-arc/d_uxoDpYg8BiVilE/26.4/images/version_control_repository_list.png?fit=max\&auto=format\&n=d_uxoDpYg8BiVilE\&q=85\&s=4caa8b6cd1106ec27e4a1fbfde7ef242)

For each repository, the list shows:

* The Git provider and the repository name
* The scope: **Global**, or the name of the workspace
* The current branch
* The number of local changes
* The number of incoming commits

A repository with no remote is labeled **Local** in the scope.

Each row in the list provides the following actions:

* **Commit & Push** (or **Commit** for a repository with no remote): opens the [Local Changes](#commit-and-push-new-changes) flyout with that repository preselected.
* **Pull**: pulls the incoming commits for that repository.
* **Select**: makes that repository the selected repository. The current repository shows **Selected** instead.

Actions that you start from a row always apply to that row's repository. If a repository is in conflict, its row shows the message *Conflicts within repo. Please go to repo to resolve conflicts.* Open that repository to resolve the conflict (see [Manage Commit and Pull Conflicts](#manage-commit-and-pull-conflicts)).

### Branch

Branch management allows you to maintain separate configuration versions for different purposes, such as development, testing, and production environments. Branches belong to a single repository, so the branches that you see and the branch changes that you make apply to the selected repository only. 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](#create-branches) and [Delete Branches](#delete-branches) for details.

### Logging

All version control changes are captured in the [Audit logs](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/activity.md#audit-logs) section of the [Activity](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/activity.md) page. You can download logs from that page as necessary.

![Audit logs for version control changes](https://mintcdn.com/cdata-arc/JuVWSaGlKX7avH_C/26.4/images/version_control_audit_logs.png?fit=max\&auto=format\&n=JuVWSaGlKX7avH_C\&q=85\&s=7337feb661705e740369380d4e9b97c8)

## History Viewer

Once version control is enabled, a **Commits History** tab appears on the **Activity** page. It shows the commit history of one repository at a time 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](https://mintcdn.com/cdata-arc/d_uxoDpYg8BiVilE/26.4/images/version_control_commit_history.png?fit=max\&auto=format\&n=d_uxoDpYg8BiVilE\&q=85\&s=bd911cdc542733a0a575f43d3c6098b0)

* Use the **Repository** filter to choose which repository's history the table shows. The tab shows the history of a single repository, not a combined history of all repositories: the table does not include a repository column, and there is no option to show all repositories at once. Actions on a row, such as pull and restore, apply to the repository whose history you are viewing. If no repository is configured, the tab shows *No repositories available*.

* Use the **All-time** and **All Users** filters to further narrow your results.

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](https://mintcdn.com/cdata-arc/d_uxoDpYg8BiVilE/26.4/images/version_control_commit_details.png?fit=max\&auto=format\&n=d_uxoDpYg8BiVilE\&q=85\&s=b5b14f70fc7bd51fdc0ac939398b01c2)

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

Click **View with all settings** in a section to see the full list of settings in that section, including those that were not changed in the commit.

![Commit details showing all settings](https://mintcdn.com/cdata-arc/d_uxoDpYg8BiVilE/26.4/images/version_control_commit_details_all_settings.png?fit=max\&auto=format\&n=d_uxoDpYg8BiVilE\&q=85\&s=10831e2d346ece0e1f850dc6a00df293)

The **Go To Resource** link on the **File Changes** tab takes you to the part of Arc where the file was changed. For example, if you are viewing the diff of a [MySQL](../../connectors/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 Arc'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

> [!NOTE]
>
> This workflow applies to remote repositories only.

Pull applies to the selected repository. To pull a different repository, either select it first or click **Pull** on its row in the [repository list](#select-a-repository).

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](https://mintcdn.com/cdata-arc/d_uxoDpYg8BiVilE/26.4/images/version_control_pull.png?fit=max\&auto=format\&n=d_uxoDpYg8BiVilE\&q=85\&s=16bc355aee1740236ce5a36d32d64fcd)

* 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](https://mintcdn.com/cdata-arc/d_uxoDpYg8BiVilE/26.4/images/version_control_pull_remote_commits.png?fit=max\&auto=format\&n=d_uxoDpYg8BiVilE\&q=85\&s=d3490b81925f1f5ff18bee2a225762d2)

### 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](https://mintcdn.com/cdata-arc/d_uxoDpYg8BiVilE/26.4/images/version_control_switch_branch.png?fit=max\&auto=format\&n=d_uxoDpYg8BiVilE\&q=85\&s=5bba02d3e01e1ef189ff000e622160a2)

Click **Add Branch** and give your branch a **Name**. Choose which branch to copy from, then click **Add**.

![Add branch dialog](https://mintcdn.com/cdata-arc/JuVWSaGlKX7avH_C/26.4/images/version_control_add_branch.png?fit=max\&auto=format\&n=JuVWSaGlKX7avH_C\&q=85\&s=4ecaf731a9fab5fc69a96654e3838f56)

### 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](https://mintcdn.com/cdata-arc/d_uxoDpYg8BiVilE/26.4/images/version_control_delete_branch.png?fit=max\&auto=format\&n=d_uxoDpYg8BiVilE\&q=85\&s=fd1cbe700050379ada97f0b82c21d074)

### Commit and Push New Changes

When you are making changes in Arc, the toolbar shows the total number of files that have been changed in the selected repository:

![Git toolbar showing number of changed files](https://mintcdn.com/cdata-arc/d_uxoDpYg8BiVilE/26.4/images/version_control_footer_toolbar.png?fit=max\&auto=format\&n=d_uxoDpYg8BiVilE\&q=85\&s=d59c1b1cf3d5ea75acdc08db5941353f)

Click **Commit & Push** to open the **Local Changes** flyout. It shows details about the files that you have changed in the selected repository. You must supply a commit message before you can commit and push your changes to remote.

The flyout header contains a repository selector that shows the name, scope (**Global** or workspace name), and branch of the repository that you are committing to. It also provides refresh and help icons, and a button that shows how many of the changed resources are selected for the commit. Use the checkboxes in the **Select Resources** list to choose which changed resources to include.

![Local Changes flyout with the repository selector in the header](https://mintcdn.com/cdata-arc/d_uxoDpYg8BiVilE/26.4/images/version_control_local_changes_flyout.png?fit=max\&auto=format\&n=d_uxoDpYg8BiVilE\&q=85\&s=a03cb0a7204e6c70c589241ba46ea3e1)

To commit to a different repository, click the repository selector in the header and click **Select** next to the repository that you want. The changed files, branch, status, and commit message update to match the repository that you chose.

![Repository selector open in the Local Changes flyout](https://mintcdn.com/cdata-arc/d_uxoDpYg8BiVilE/26.4/images/version_control_local_changes_repository_list.png?fit=max\&auto=format\&n=d_uxoDpYg8BiVilE\&q=85\&s=f014d66af9546299fd6495122efcfa25)

> [!NOTE]
>
> 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.

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 and use the **Repository** filter to choose the repository that contains the resources. Restore applies only to that repository. Click the ellipsis 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

> [!NOTE]
>
> 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. Conflicts are tracked per repository: a conflict in one repository does not block actions in another. 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. In the [repository list](#select-a-repository), a repository in conflict shows the message *Conflicts within repo. Please go to repo to resolve conflicts*.

![Commit and pull conflict message in toolbar](https://mintcdn.com/cdata-arc/d_uxoDpYg8BiVilE/26.4/images/version_control_commit_pull_conflict.png?fit=max\&auto=format\&n=d_uxoDpYg8BiVilE\&q=85\&s=547294a385ffb1bf84653946ac11f754)

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 in the selected repository, 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.

You can also discard changes on the **Local Changes** flyout. Select the resources to discard, then use the dropdown arrow on the **Commit...** button and choose **Discard Changes**. Review your selections, then click **Discard Changes**.

## Migrate from a Local to a Remote Repository

If you have a local repository and want to connect to a remote server while preserving your commit history, you can convert it to a remote repository. This works for global and workspace repositories.

1. Create the remote repository: set up a new, empty repository on your Git platform (such as GitHub, GitLab, or Bitbucket).

2. Open the version control settings: for the global repository, navigate to **Settings > Advanced > Git Version Control**. For a workspace repository, open the workspace, then click **Settings** in the ellipsis menu. Click the **Git Version Control** tab.

3. Change the Configuration Type from **Local** to **Remote**.

4. Enter the remote repository URL and your authentication credentials. See [Git Version Control Settings](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/git-version-control-settings.md) for the available authentication schemes.

5. Click **Save**. Arc adds the remote to the repository and applies your credentials. Once your **Status** shows **Connected**, click **Commit & Push** to send your existing local commits to the remote repository.

Your local commit history and tracked files are preserved. Arc does not recreate the underlying `.git` directory.

## Convert a Remote Repository to a Local Repository

To stop syncing a repository with its remote while keeping its history, open the version control settings for the global or workspace repository, change **Configuration Type** from **Remote** to **Local**, and click **Save**. Arc cleanly removes the remote from the repository. Your local commit history and tracked files are preserved, and **Pull** is no longer available for that repository.

## Edit the Remote URL

You can change the repository URL after version control is initialized. To change the remote URL for a repository that is already connected to a remote:

1. Open the version control settings for the repository. For the global repository, navigate to **Settings > Advanced > Git Version Control**. For a workspace repository, open the workspace, then click **Settings** in the ellipsis menu. Click the **Git Version Control** tab.
2. Edit the repository URL and, if required, your credentials.
3. Click **Save**.

Arc updates the remote and applies the credentials. Your local commit history and tracked files are preserved.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.