With Git Integration, every change to your Knowledge Base is tracked, versioned, and reversible - giving your team the confidence to iterate fast without ever losing progress.

Configure Git

Setting up Git in HEDDA.IO is a one-time configuration per Project. Provide the following details to link your Project to your Git server.

Once all fields are filled in, click Switch to Git to complete the configuration.

Once the 'Switch to Git' button is pressed, there is no going back for the respective Project. This action cannot be reversed.

Version: Create, Select, Operate

Git projects support multiple simultaneous Edit Versions. Each version is stored as a separate branch in the repository.

Key Behaviours

• Changes made inside an Edit Version do not affect the Live Knowledge Base or any other version until you publish.
• When multiple versions exist in parallel, you can switch between them and resume work on a specific one.
• One user can only operate inside one Edit Version at a time.

Create a Version

1. Open a Knowledge Base.
2. Click Edit Version (top-right).
3. In the dialog, select the Add Version tab.
4. Enter a name between 3 and 50 characters.
5. Click Ok to create and enter the version.

Select an Existing Version

1. Open a Knowledge Base.
2. Click Edit Version (top-right).
3. In the dialog, select the Select Version tab.
4. Choose the version from the list.
5. Click Ok to open it.

Discard Version

Discard works differently when Git is configured. Rather than a single action, it gives you two options depending on what you actually want to do with the version.

Linked Environment Branch

A Linked Environment Branch is an optional pointer to another environment's branch within the same repository. It tells HEDDA.IO where to look for incoming changes, making the current Project aware of what another environment has published.

Without it, HEDDA.IO has no way to detect or pull changes from another environment. Setting it activates the Has Differences indicator on the Project Dashboard and enables the Synchronize flow.

How it Works

The Linked Branch (source environment) is monitored by HEDDA.IO. When it contains changes not yet present in the current Environment Branch (target), HEDDA.IO shows a Has Differences indicator. From there, you can Synchronize or Replace.

- Both environments must share the same repository. Cross-repository linking is not supported.
- The Linked Branch is always the source. The current Environment Branch is always the target.

Synchronization and Replacement

When the Linked Environment has changes not yet in the current Project Environment, HEDDA.IO shows a Has Differences indicator on the Project Dashboard. Two choices are then presented:

Replace is irreversible. All existing content in the target environment will be permanently overwritten. There is no undo.

External Connections Handling

External Connection credentials are stored locally within each Project and are never committed to Git. When a Knowledge Base is brought into a new environment via Synchronize or Replace, the structure and configuration arrive intact - but the connection references are blank, because the target environment has no knowledge of the source environment's credentials.

During Synchronization or Replacement, HEDDA.IO prompts you to resolve any missing External Connections before the import completes.

Connection Resolution Steps

1. Connection Missing Prompt
   • When HEDDA.IO detects missing connections, it presents a list of affected objects and prompts you to assign an External Connection to each one. This can include Data Links or External Members.
2. Select a Connection and click Link
   • Choose the appropriate External Connection from the dropdown and click Link to map the object to its data source.
3. Connection Validation
   • HEDDA.IO verifies the source is reachable and contains the entities referenced in the configuration. If validation fails, the connection must be corrected before the import can proceed.

The prompt lists only objects with missing connections. Already-linked objects are not affected by the import.

Conflict Resolution

In Git terms, a conflict occurs when the same area of the Knowledge Base has been modified on both sides of a merge

- triggered either by Synchronization between environment branches, or by publishing an Edit Version against a Live state that has moved on since the branch was created.

Conflict Resolution Steps

1. Has Conflicts appears
   • The Project Dashboard Git section shows the Has Conflicts indicator. Click Fix to open the resolver.
2. Inspect side by side
   • Select the conflicting item from the list. A side-by-side view shows the Linked Branch state (left) vs the Environment Branch state (right).
3. Choose which side wins
   • Pick the Linked Branch or the Environment Branch for each item. One side wins entirely - no field-level cherry-picking is possible.
4. Resolve
   • Confirm the resolution. The environment is updated with the chosen state. The conflict is cleared.

Choosing a side is all-or-nothing per item. If the winning side is missing a change you need, you will have to reapply it manually after resolution.

Cancelling closes the conflict resolver entirely. The conflict is not saved or paused - you will need to retrigger Sync or Publish to open the resolver again.

Environment Promotion

Environment Promotion moves your Knowledge Base through a controlled pipeline of environments. The following example uses DEV, QAS, and PROD as the standard pipeline.

How it Works

After publishing in DEV, open the QAS Project. Git shows Has Differences > click Synchronize or Replace to import. Repeat from QAS to PROD. Missing External Connections are reconfigured during the process.

Quick Reference Guide

If you have any further questions, please feel free to Contact Us.