# Overview Source Control in Nected lets your teams version, manage, and collaborate on all automation assets using Git. It introduces a structured development workflow where every change is tracked, reviewed, and promoted through a predictable lifecycle—whether you use GitHub today or Git providers in the future. {% hint style="info" %} If you are running the **On-Premise Agent**, upgrade to **v1.0.5+** to enable Source Control. {% endhint %} Source Control is optional, but once enabled: * The Git panel shows real-time sync status (Ahead, Behind, Ahead & Behind) * Any difference between your workspace and the selected Git branch becomes visible through sync indicators This allows teams to build safely, test confidently, and maintain full traceability across all Synced Entities. ### **Why Source Control Matters** Source Control provides a unified, auditable development workflow across Rules, Workflows, Integrations, Datasets, Variables, and other Synced Entities. It gives every contributor—engineering, product, or business—access to the same disciplined lifecycle your software organization already uses. With Source Control, your teams can: * Version every structural change to Synced Entities in Git * Work on multiple branches without affecting production * Collaborate through pull requests, reviews, and approvals * Merge changes safely using Git workflows and protection rules * Push and pull updates between Nected and your repository * Maintain full historical lineage of all updates * Resolve sync conflicts with clear UI options inside Nected This ensures accuracy, repeatability, compliance, and safer collaboration across your entire automation development pipeline. ### **What Gets Synced /** Not Synced Nected syncs the following assets into your connected Git repository: | Resource Type | What Is Tracked | | ---------------------- | --------------------------------------------------------------------- | | **Rules** | Everything including published versions | | **Workflows** | Everything including published versions | | **Integration** | Name and metadata except the configuration and the credentials. | | **Datasets** | Everything | | **Cron/Schedulers** | No. Enabled only on the default branch if Git is enabled in Nected | | **Workspace Settings** | No | | **Teams & Users** | No | | **Variables** | All the global and secret variables (only names, not the credentials) | Any integration configs and sensitive credentials (like authorizations and api\_key) are never exported in Git sync, only the references with the names. You need to update those configs manually during/after sync. ## **How It Works (Development Lifecycle)** Source Control in Nected follows a clear Git-driven lifecycle that matches the way modern engineering teams build, review, and deploy software. When you enable Source Control, all changes to your Nected workspace flow through Git—ensuring traceability, predictability, and controlled releases. The full lifecycle includes:\ **Repository setup → Branch selection → Push/Pull operations → Review & Merge → Production deployment** {% @mermaid/diagram content="graph LR A\[Setup Repository] B\[Configure Branch] C\[Push Changes] D\[Review & Merge] E\[Pull Changes on Nected] A --> B B --> C C --> D D --> E" %} Below is the complete flow, including how it behaves across workspaces. ### **1. Connect Git Repo** The lifecycle begins when the workspace admin prepares the Git repository. #### **Create a Personal Access Token (Git Admin)** Before any workspace admin connects or authenticates with the Git repository, the **Git Admin** (or Workspace Admin with GitHub access) must create a **Personal Access Token (PAT)**. This token is required for Nected to push and pull changes to the repository. You may use either:
Fine-Grained Personal Access Token When generating a Fine-grained PAT: * Select the **specific repository** that will be connected to Nected * Under **Repository Permissions**, grant: * **Contents → Read & Write** * No additional permissions are required Fine-grained tokens offer better security and are preferred for production work.
Classic Personal Access Token If using a Classic PAT: * Only the **repo** permission (Read & Write) is required * No other scopes are needed Classic tokens are simpler but less restrictive than fine-grained tokens.
After that, give the PAT to your workspace admin (or if you're the workspace admin, then save it), as now the admin needs to configure the git through UI. {% hint style="info" %} **Note:** Connecting a Git repository, selecting the default branch, setting the token, and completing initial configuration can only be done by a **Nected workspace admin**. {% endhint %} Based on your access to the workspace, your flow of connecting to Git will be different. Here are the two flows:
If you're a Workspace Owner / Primary Admin This flow applies only to the **workspace owner** or the first **workspace admin** responsible for configuring Source Control. **This admin performs the full Git setup once per workspace.**
**Steps:** 1. Create a **blank GitHub repository**. 2. Generate a **Personal Access Token** (Fine-grained or Classic) with **Read/Write** permissions. 3. In Nected, go to **Git Repository → Connect to Git**. 4. Enter the: * **Repository URL** (HTTPS or SSH) * **Personal Access Token** 5. Nected connects to the repository and fetches the available branches. 6. If no branch exists, `master` becomes the automatic default. 7. If multiple branches exist, select the **default branch** for the workspace.
If you're an Additional Workspace Admins This flow applies when the workspace owner adds another user **and assigns them the Admin role**. In this case, the repository is **already connected**, so the new admin only needs to add their own PAT.
**Steps:** 1. The Git repository is already configured by the primary admin. 2. The new workspace admin opens **Git Repository → Add Personal Token**. 3. Enter a valid **Personal Access Token** provided by the Git admin. 4. This token grants the admin permission to work on authorized branches.
[Learn more about how to connect with GitHub](https://docs.nected.ai/nected-docs/development-lifecycle/git-based-source-control/setup/github) {% hint style="warning" %} **Note:** The Git repository is immutable once connected. Choose the correct repository during setup. {% endhint %} ### **2. Select Branch** Once the Git repository is connected and authenticated, the next step is selecting the branch you will work on. [Learn about how to set your Branch](https://docs.nected.ai/nected-docs/development-lifecycle/git-based-source-control/branches)
#### **For Primary Workspace Admin** * After connecting the repo, Nected automatically detects all branches. * If the repository has **no branches**, GitHub’s default (`master`) becomes the workspace’s default branch. * If multiple branches exist, the admin can select the **default/base branch**, typically `main` or `master`. Only the **primary workspace admin** defines this default branch, and it is configured **once** per workspace. #### **For Additional Workspace Admins** * Additional admins **do not choose the default branch**—it is already set by the primary admin. * They only see and can switch to **branches they have been granted access in GitHub**. This ensures full alignment with GitHub’s access and security rules. ### **3. Creating & Editing Logic in Nected** Once connected: * Users create or modify Rules, Workflows, Datasets, Integrations, API triggers, and Schedulers. * **Every change is auto-saved locally**. * The Git panel shows whether the workspace is: * **Ahead** (local changes not pushed), * **Behind** (remote changes not pulled), or * **Ahead & Behind** (diverged). Changes remain local until committed. ### **4. Commit & Push** Users commit changes directly from the Nected UI: * **Workspace-level commits** (push everything modified) * **Resource-level commits** (push only a specific Rule, Workflow, or Dataset) [Learn more about how to Push changes](https://docs.nected.ai/nected-docs/development-lifecycle/git-based-source-control/commit-and-push) {% hint style="info" %} During a push, all versions of all Synced Entities are included: **Draft, Staging, Published** {% endhint %} The push writes the changes to the selected branch in Git.
#### **Review and Merge** * Merge approval is **not handled in Nected**. * PR creation, review comments, merge approvals, and conflict resolution all occur in **GitHub**. * GitHub remains the authority for: Code governance, Branch protection, Review rules, Merge decisions ### **5. Pull & Update Workspace** After a PR is approved and merged in GitHub:
* Users click **Pull** in Nected to import the updated branch state. * Nected updates all corresponding entities and resolves conflicts through: **Merge & Pull, Override & Pull, Archive / Archive Overwrite** (when conflicts exist) [Learn more about how to pull changes and Sync](https://docs.nected.ai/nected-docs/development-lifecycle/git-based-source-control/pull-changes) This ensures the workspace always reflects the current branch state. Actual deployment of infrastructure or Nected runtime remains outside the GitHub Sync scope and is controlled via your hosting or GitHub-based CI/CD pipeline. > Teams who want to automate publishing and environment promotion can use **GitHub Actions** for scripted deployment flows.