Connecting Projects To Git Providers For Source Based Workfl

Understanding how Git connections support connected projects

In Atloria, a Git provider connection is what lets a project use repository-based content during connected project setup and later source-based documentation work. You use this connection when your team wants Atloria to work from a repository instead of relying only on manually entered project details. The connection links Atloria to the Git provider account that can access the repository your project depends on.

It helps to separate two actions that often happen close together:

• Connecting a Git provider gives Atloria permission to reach your Git account or organization.
• Choosing a repository tells Atloria which specific repository the project should use.

These are related, but they are not the same step. You can think of the provider connection as the access pass, and the repository selection as the actual source you want to use for the project.

An active connection matters after setup as well. Ongoing tasks that depend on it can include:

• keeping the project linked to its repository
• allowing Atloria to continue using source-based project setup
• maintaining repository access when permissions change
• supporting future source-backed documentation work tied to that connected project

The main places you will use in Atloria are the project area where connected setup is managed, the project settings or integration area where the provider appears, the visible connection status, and the controls for Re-authorize, Reconnect, or Disconnect when access changes.

If you are still deciding whether to use a connected setup or a manual project setup, read Choosing Between Manual and Connected Project Setup.

Checking access requirements before you connect a provider

Before you start the connection flow in Atloria, make sure you are signed in with a role that can manage project-level setup and integrations. For most teams, that means a role such as Project Administrator or Documentation Manager. If you can open the project settings area and see connection controls, you likely have the right level of access. If those controls are missing, ask a project admin to review your permissions.

You also need access on the Git provider side. The account you use during sign-in must be able to reach the repository, workspace, or organization that owns the source content for the project. If the repository belongs to a team or company account rather than your personal account, confirm that you can view it there before starting the connection in Atloria.

During the provider approval screens, you may be asked to grant access to repositories or organizations. Read those choices carefully. If you approve the wrong account or skip repository access, Atloria may show the provider as connected but still not be able to use the repository your project needs.

Before connecting, confirm these points:

• You are signed in to Atloria.
• You can open the correct project.
• You have permission to manage project setup or integrations.
• You know which Git provider hosts the repository.
• You can sign in to the correct provider account or organization.
• You are ready to approve repository or organization access if prompted.

It also helps to identify the exact project that will use the connection. If your team manages several projects in Atloria, open the intended project first so you do not connect the provider in the wrong workspace.

For help getting into your account or resolving sign-in issues first, see Signing In to Atloria and Solving Access Problems.

Connecting a Git provider to a project

1. In Atloria, open the project you want to use for source-based documentation work. Go to the area where connected setup or project integrations are managed. Look for the option to connect a Git provider.

2. In the connection area, choose the provider you want to use from the available options. Atloria will start the authorization flow and send you to the provider sign-in and approval screens.

3. Sign in with the Git provider account that has access to the repository your project needs. If the provider asks you to choose an account, organization, or repository scope, select the one that matches the project’s source location.

4. Review the consent screen carefully, then approve access. If the provider asks whether Atloria can access repositories or organization content, allow the access needed for the project you are connecting.

5. After approval, return to Atloria automatically or through the browser flow. Back in the project area, check the connection section again.

6. Confirm that the provider now appears as connected. The project’s integration or source setup screen should show that the authorization step completed successfully.

A successful connection usually means you can move forward with repository selection or continue a connected project setup that depends on source access. If the provider appears, but the repository you need is still unavailable, the most common cause is that the wrong provider account was approved or repository access was not included during consent.

Use this screen to confirm:

• the provider name is shown
• the status indicates an active connection
• the project is ready for the next source-based step

[SCREENSHOT: Git provider selection screen in a project] [SCREENSHOT: Connected status shown after returning from provider authorization]

Reviewing connection status and repository access

Once a provider is connected, the next thing to check is the visible status in the project settings or connected project configuration screen. This status tells you whether Atloria can still use the provider for repository-backed work.

You may see status labels such as these:

When the status is Connected, review the connection details shown on the screen. Check that the connected provider account matches the repository owner, team, or organization your project depends on. This matters most when you belong to multiple provider accounts or organizations. A connection to the wrong account can look valid at first but still fail when Atloria tries to work with the intended repository.

Look for visible details that help confirm the setup, such as:

• the connected provider name
• the current connection state
• whether authorization is still valid
• whether the project is still linked for connected source-based work

If the screen shows Authorization Required, do not assume the project is fully usable just because a provider name is listed. That status means Atloria recognizes the previous connection, but you need to refresh access before continuing.

If you want a deeper walkthrough focused on health checks and warning states, continue with Reviewing Git Connection Status and Access Health.

Re-authorizing a Git provider when access changes

1. Open the project in Atloria and go to the same connection area where the provider status is shown. If the status reads Authorization Required, or if the screen indicates expired access or missing permissions, select Re-authorize or Reconnect.

2. Atloria will send you back through the provider approval flow. Sign in with the correct provider account, especially if you have access to more than one account or organization.

3. On the provider consent screens, approve the access Atloria requests. If your team recently moved the repository, added a new organization, or changed repository permissions, make sure you grant access to the newly required location.

4. Finish the approval flow and return to Atloria. Go back to the project connection area and refresh the page if needed.

5. Confirm that the status changes from Authorization Required back to Connected.

Re-authorization is useful when the original connection still belongs to the right project, but the access behind it has changed. In that case, you usually do not need to rebuild the project from scratch. Instead, you refresh the existing connection so Atloria can continue using the same connected setup.

This is especially helpful when:

• repository permissions were updated
• your team changed which organization owns the repository
• the provider asked for approval again
• Atloria reports that access is no longer valid

After re-authorizing, verify that the project can continue with the same repository-backed workflow. If the status returns to Connected, the existing setup should remain in place without creating a brand-new project connection.

For a fuller guide to ongoing access maintenance, see Connecting Projects to Git and Maintaining Access.

Disconnecting a provider and verifying the project setup

1. In Atloria, open the project and go to the Git provider connection controls in the project settings or connected setup area.

2. Select Disconnect from the available connection actions. Atloria may show a confirmation message before completing the change.

3. Read the confirmation message carefully. This is where Atloria explains how disconnecting affects connected project setup and any source-based work that depends on repository access.

4. Confirm the disconnect action. After the action finishes, stay on the same screen and check the updated status.

5. Verify that the provider now shows as Disconnected.

After disconnecting, review the project setup to understand what changed. A disconnected provider means Atloria no longer has active access to the repository through that project connection. If your project depends on repository-backed documentation workflows, those tasks will usually require a new connection before they can continue.

Use the project screen to confirm:

• the provider is no longer marked as connected
• connection actions now offer a way to reconnect
• the project no longer has an active source access link

Disconnecting can be the right choice if the project is moving to a different provider account, if the wrong account was connected, or if your team no longer wants the project tied to that repository access. If you only need to restore access, use Re-authorize instead of disconnecting so you can keep the existing connected setup intact.

If you need to remove and later restore access safely, the next documents in this section cover those follow-up tasks in more detail, including Reauthorizing and Disconnecting Git Integrations.

Overview

This document focuses on the project-level workflow for using Git provider access in Atloria’s connected project setup. The key idea is that a provider connection gives Atloria permission to work with a repository-backed project, while the repository choice determines which source the project actually uses. Both parts matter, but they happen as separate actions in the interface.

The screens you will use most often are:

• the project area where connected setup begins
• the project settings or integration area
• the Git provider status section
• the Re-authorize, Reconnect, and Disconnect controls

Across those screens, you will typically complete four tasks:

• connect a provider for the first time
• confirm the connection is still active
• re-authorize access when permissions change
• disconnect the provider when the link is no longer needed

This guide stays focused on what you can see and do in Atloria. It does not cover provider-specific account administration outside the approval screens, and it does not repeat the broader project onboarding flow. If you need the full setup path before reaching the Git connection step, start with Creating Projects and Completing Onboarding.

If you are comparing setup styles before you commit to a repository-backed workflow, use Choosing Between Manual and Connected Project Setup. If your project is already connected and you mainly need to monitor status or fix access drift, the follow-up documents in this Git Connections section will take you through those maintenance tasks in order.

The next step after this guide is Connecting Projects to Git and Maintaining Access.

Prerequisites

Before you connect a Git provider in Atloria, make sure the project and your access are ready. This keeps the connection flow short and helps avoid the most common problems, such as approving the wrong account or connecting from the wrong project.

Have these items in place:

• You can sign in to Atloria successfully.
• You can open the correct project workspace.
• Your role allows you to manage project setup or integrations.
• You know which Git provider hosts the repository.
• You can sign in to the correct provider account.
• You have access to the repository owner or organization if the repository is team-managed.

It is also worth checking a few details before you click Connect:

If your team uses several Atloria projects, pause and verify the project name before starting the provider flow. If you belong to several Git organizations, verify which one owns the repository so you can choose the right account during sign-in and consent.

You do not need to complete advanced admin setup to follow this guide, but you do need enough project access to see the connection controls. If those controls are unavailable, review your project permissions with an administrator. For broader admin navigation, see Using the Admin Workspace.