Connecting Projects to Git and Maintaining Access

Checking what you need before connecting a Git provider

Before you open the Git integration area in Atloria, make sure you are working in the correct project and that you can access the project’s settings. Git connections are managed from the project settings area, so you need the level of access that lets you open Settings and work with Integrations. If you cannot see Settings > Integrations > Git, ask a Project Administrator to confirm your access before you continue.

You should also know which Git provider you plan to connect. On the Connect provider screen, Atloria shows the supported provider options available for your workspace. Choose the one that matches the account where your project’s repositories are stored. If your team already decided on a provider during setup, follow that choice here rather than connecting a different account.

Before starting the connection, confirm that you can sign in to the target Git account without needing help from someone else. The connection process sends you through the provider’s sign-in and approval window, and you must complete that step yourself. If you are already signed in with the wrong account in another browser tab, sign out there first or be ready to switch accounts during authorization.

It also helps to confirm how your team organizes access on the provider side. Some teams work under a shared organization or workspace, while others use personal repositories. During authorization, you may need to approve access for a specific organization, workspace, or repository scope. If you are not sure which one your project should use, check your team’s setup notes from Connecting Projects to Git Providers for Source Based Workflows before you connect.

Connecting a project to a supported Git provider

1. Open the project in Atloria where you want to maintain the Git connection.

2. In the project navigation, open Settings, then go to Integrations, and select Git. This is the project-level area where Atloria shows the current provider connection or lets you start a new one.

3. Click Connect provider. Atloria opens a provider selection screen with the supported options available to your project. Choose the provider your team uses for this repository.

4. After you select the provider, Atloria starts the authorization flow. A sign-in or consent window opens for that provider. If prompted, sign in with the Git account that should be linked to this project.

5. Review the provider’s approval screen carefully. Depending on how your team manages source access, you may need to allow Atloria to work with a specific repository, a group of repositories, or an organization-level workspace. If the provider asks you to confirm organization or repository access, select the option that matches the project you are connecting.

6. Finish the approval flow and return to Atloria. When the connection is successful, the Git integration panel updates to show that the project has an active connection.

7. Confirm the provider card or connection panel now shows the linked provider and an active status. If Atloria still shows a setup prompt instead of a connected state, refresh the page once and check again.

This process links the current Atloria project to the selected Git provider account. If you need help choosing the right provider for a new project, use Connecting Projects to Git Providers.

Reviewing connection status and linked account details

Once a Git provider is connected, return to Settings > Integrations > Git whenever you want to confirm that access is still healthy. Atloria uses the Git integration status area to show whether the project is currently Connected, Requires re-authorization, or Disconnected. This is the first place to check if repository access stops working or if a teammate reports that Atloria can no longer reach the source repository.

When the status is healthy, the provider panel should show Connected along with the provider name and the linked account details. Use this area to confirm you are connected to the expected account, especially if you manage more than one Git identity. A mismatch here can explain why the project cannot see the repository your team expects.

Atloria may also show when access was last authorized. That detail helps you understand whether the current grant is recent or whether it may have gone stale after an account change. If your organization recently changed repository visibility, moved a repository into a different workspace, or updated who can approve integrations, the last authorization date can help you decide whether to reconnect or re-authorize.

Pay attention to warning states. A status such as Requires re-authorization usually means Atloria can no longer use the original approval. This can happen after password resets, account membership changes, removed repository access, or expired provider-side approval. A fully Disconnected state means the project no longer has an active Git link at all.

If you want a broader review of what these statuses mean in day-to-day work, continue with Reviewing Git Connection Status and Access Health.

Re-authorizing access when the connection needs attention

1. Open the project in Atloria and go to Settings > Integrations > Git.

2. Look for a warning state such as Requires re-authorization. Atloria uses this status when the project still has a saved connection record, but the linked provider access is no longer valid enough to use normally.

3. Click Re-authorize. This is different from starting over with a new connection. Re-authorizing updates the existing project connection so you can restore access without replacing the integration unnecessarily.

4. Atloria opens the provider’s approval window again. Sign in with the same Git account your project should use, unless your team has intentionally moved the project to a different approved account.

5. Review the requested access carefully before you approve it. This step matters most when repository visibility changed, your team moved the repository into a different organization or workspace, or your account permissions were updated since the original connection.

6. Approve the request and return to Atloria. After the provider sends you back, wait for the Git integration panel to refresh.

7. Confirm the status changes back to Connected. Also check that the linked provider and account details still match the project you are maintaining.

If the status does not change right away, refresh the page and review the connection panel again. If Atloria still shows a warning, repeat the re-authorization flow and make sure you completed the provider’s final approval step instead of closing the window early.

For cases where you need to replace or remove the connection entirely, use Reauthorizing and Disconnecting Git Integrations.

Disconnecting a Git integration safely

1. Open the project in Atloria and go to Settings > Integrations > Git.

2. In the existing connection panel, click Disconnect or Remove integration, depending on the label shown in your workspace. Atloria uses this action to break the project’s current link to the provider account.

3. Read the confirmation prompt before you continue. Atloria should make it clear that the project will lose access to the linked Git provider account once you confirm. This is especially important if your documentation workflow still depends on repository access for updates or source-based work.

4. Confirm the action. Atloria removes the active connection from the project and updates the integration status.

5. Check the Git panel again and make sure the status now shows Disconnected or returns to the setup state where Connect provider is available.

Disconnecting in Atloria removes the project’s active link, but your organization may also require a second cleanup step on the provider side. If your security policy calls for full removal, open the Git provider’s authorized applications or connected apps area and remove Atloria there as well. That provider-side cleanup is separate from the Atloria disconnect action, so do not assume one automatically completes the other.

Use extra care before disconnecting a shared project. If multiple team members rely on the same repository connection, confirm with the project owner or documentation lead first. Removing the connection from the wrong project can interrupt source-based documentation work and force the team to reconnect later.

Verifying the project's Git access after connecting or updating permissions

After you connect, re-authorize, or disconnect a provider, return to Settings > Integrations > Git and refresh the page once. The provider card should reflect the latest state. If you just completed a connection or re-authorization, look for Connected and confirm the linked account matches the one you intended to use. If you disconnected the integration, the page should show Disconnected or offer Connect provider again.

When the project was re-authorized because of permission changes, verify more than the status label. Check that the project still has access to the intended repository scope, organization, or workspace that your team expects. A connection can appear active while still pointing to the wrong account or a narrower access scope than before. This is especially important after role changes or repository moves.

If the status does not update after a successful approval screen, try these checks:

• Refresh the Git integration page.
• Reopen Settings > Integrations > Git and confirm the provider card changed.
• Repeat the authorization flow and complete every step in the provider’s consent window.
• Make sure you approved access with the correct Git account.

If you disconnected the project but want to be certain access is fully removed, verify both sides:

• In Atloria, confirm the project no longer shows an active provider connection.
• In the Git provider account, confirm Atloria is no longer listed in the authorized applications area if your team requires provider-side cleanup.

For a deeper review of ongoing connection health after setup, continue with Reviewing Git Connection Status and Access Health.

Overview

This document focuses on the day-to-day Git connection tasks you perform inside a project after your team has already decided to use a source-based workflow. In Atloria, those tasks happen in Settings > Integrations > Git, where you connect a provider, check whether access is still active, re-authorize a connection that needs attention, and disconnect a provider when the project should no longer use it.

Use this guide when you need to answer practical questions such as:

• Is this project currently connected to a Git provider?
• Which provider account is linked to the project?
• Why does the connection show a warning instead of Connected?
• How do I restore access without creating a brand-new connection?
• How do I remove the provider link cleanly?

This guide does not repeat the earlier setup planning covered in Connecting Projects to Git Providers for Source Based Workflows. Instead, it assumes you already know why the project needs a Git connection and are now working with the actual integration controls inside the project settings.

The most important screen throughout this process is the Git section under Integrations. That screen is where Atloria shows the provider card, the connection status, the linked account details, and the actions available for the current state, such as Connect provider, Re-authorize, Disconnect, or Remove integration. If you are troubleshooting access, start there before trying anything else.

After you finish the steps in this guide, the next document to read is Connecting Projects to Git Providers, which continues with provider connection work in the broader Git Connections sequence.

Prerequisites

Before you work with a project’s Git connection in Atloria, make sure these basics are in place:

• You can open the correct project in Atloria.
• You have access to Settings for that project.
• You can see Integrations > Git in the project settings.
• You know which Git provider your team wants to use for this project.
• You can sign in to the Git account that should be linked.
• You are ready to approve access in the provider’s authorization window.

A few checks can save time before you start:

If your project has not been prepared for a Git-based workflow yet, go back to Connecting Projects to Git Providers for Source Based Workflows before continuing. If you are already ready to move from preparation into the actual provider setup flow, the next guide in this sequence is Connecting Projects to Git Providers.