Manage Git connections

Manage Git connections from Git Integration. Connection administration is organization-scoped; repository creation additionally requires project-admin access.

Typical time

5–10 minutes

You need

A connected Git provider

Outcome

Reviewed access and defaults

Step 1: Review the account row

In Connected Accounts, confirm provider, owner, owner type, default marker, and Connected status. Use the row action menu instead of changing provider credentials outside the approved flow.

The current row actions are Create repository, Refresh access, Set as default owner, Open GitHub/GitLab/Azure DevOps, Reconnect, and Disconnect. Provider and project-role checks can disable actions that do not apply to the selected account.

Manage Git 1 of 5 · Screenshot placeholder

Review the connected account

Show one synthetic provider account and its row action menu.

Future capture briefReplace the owner, avatar, provider organization, repositories, connection IDs, and all customer metadata.

Step 2: Refresh or reconnect

• Refresh connected Git accounts reloads the current backend-owned page.
• Refresh access re-reads the authorized provider accounts after membership or repository scope changes.
• Reconnect starts a new provider authorization flow when consent, installation, or credentials have expired or been revoked.

Do not reuse callback codes, state values, installation IDs, or tokens from a previous attempt.

Manage Git 2 of 5 · Screenshot placeholder

Refresh or reconnect access

Show Refresh access and Reconnect on a staged account, plus a safe completion notice.

Future capture briefDo not capture authorization redirects, callbacks, codes, state, tokens, provider responses, or real owners.

Step 3: Review connection defaults

Use Connection Settings to review:

• Auto-sync repositories;
• Create PR checks;
• Require approval before apply; and
• Default provider.

Defaults affect new workspace repository setup. Existing workspaces keep their saved behavior until explicitly updated.

Manage Git 3 of 5 · Screenshot placeholder

Set safe organization defaults

Show governance toggles and Default provider with Require approval before apply enabled.

Future capture briefUse a documentation organization and exclude workspace, repository, project, owner, or execution evidence.

Step 4: Review audit history

Choose View audit history. Review connection, refresh, settings, repository, and disconnect events using safe actor and organization context.

Audit evidence must not contain provider tokens, OAuth codes, passwords, repository credentials, prompt bodies, Terraform state, or unbounded customer payloads.

Manage Git 4 of 5 · Screenshot placeholder

Review Git Integration Audit History

Show redacted audit rows with action, result, time, and safe actor context.

Future capture briefReplace actors and organization identifiers. Hide tokens, URLs, repository details, request payloads, and raw provider errors.

Step 5: Disconnect safely

Choose Disconnect and review the confirmation. Disconnect removes the stored ScrinCloud provider credential and stops new automation. Repository records already created in projects are retained.

After disconnecting, also revoke the GitHub App installation or provider consent when organizational policy requires it. Disconnecting does not delete provider repositories or Terraform-managed cloud resources.

Manage Git 5 of 5 · Screenshot placeholder

Confirm provider disconnection

Show the shared disconnect confirmation with a synthetic provider account.

Future capture briefDo not show a real owner, provider identity, repository, connection ID, token, or organization.

Governed repository workflow

When publishing Terraform:

1. select an approved connected provider and project repository;
2. generate and review the Terraform revision;
3. use a governed branch;
4. run safe-file and secret checks;
5. open a pull or merge request; and
6. require the normal review and approval process before apply.

ScrinCloud must not silently overwrite remote changes or force-push across branch protection. Publishing should stop on conflicts or unsafe files.

Files such as Terraform state and plans, secrets, environment files, keys, logs, archives, binaries, and unknown hidden files are always inappropriate for repository publishing.

Provider capability summary

Action	GitHub	GitLab	Azure DevOps
Connect, refresh, reconnect, disconnect	Yes	Yes	Yes
Set as default owner	Yes	No current row action	No current row action
Create repository from Git Integration	Yes, with project-admin access	No current row action	No current row action
Select as Default provider	Yes	Yes	Yes

Check your result

Confirm the account status and owner, refresh access, review saved defaults and audit evidence, and verify that only approved workspaces and repositories can use the connection.

Common blockers

Refresh does not pick up new repositories

Review provider-side installation or OAuth scope, then reconnect if consent changed. Do not broaden access beyond the approved repositories.

Repository creation is disabled

The current action is GitHub-only and requires project-admin access plus an eligible project.

Disconnect leaves a repository visible

Disconnect retains project repository records and does not delete provider repositories. Remove provider-side consent separately when policy requires it.

A live workflow has not been proven

Source code and deployment wiring do not prove provider credentials, callbacks, webhooks, or repository permissions are healthy in a specific environment. Record live evidence only after an approved end-to-end runtime check.