Git repositories and issue sync

Connecting a personal Git account, linking a project repository and synchronizing forge issues are separate actions. Authorize the account first; the project owner then chooses the repository and can enable synchronization with the required provider permissions.

Connect Git and link a project repository

In account Git settings, connect GitHub or GitLab and complete the browser authorization. Grant access only to the repositories needed. In desktop, follow the browser return to the app. The account connection can be reused across projects; it does not automatically link every repository.

The project owner opens project settings' Git section, chooses an available repository and confirms the link. Check its provider, full repository name and displayed acting account. Members cannot replace the owner-only link. Linking enables repository context, pull request tracking and repository skills; issue synchronization is a separate switch.

Missing repositories or expired access

If the picker is empty, check provider permissions and that the intended organization or repository is authorized. Reconnect an expired account rather than entering tokens in issue text. Unlinking requires owner permission; inspect the confirmation before proceeding.

Self-hosted installations can use a configured managed relay or operator-owned provider apps. A relay connection is started explicitly; it does not make the forge local. Availability depends on instance configuration. Check the operator's provider and relay policy before authorizing access.

Synchronize linked forge issues

As project owner, open project settings' Git section after linking the repository. Enable issue synchronization only with the required provider write access. Imported forge issues enter triage. Confirm the reported backfill and inspect a known remote issue, its title, description and state before relying on synchronization.

Open and closed states mirror in both directions. For GitHub, title and body map to title and description; labels supply categories and recognized priority or effort; the first linked assignee is used, and milestone due date supplies the due date. Comments retain remote author, identity, URL and timestamps. Blocking relations require both issues in the same imported project. Original attachment URLs remain; uploaded bytes and GitHub project fields have no native equivalent.

Permissions, conflicts and disablement

GitHub App synchronization needs Issues read/write and Issues, Issue comments and Issue dependencies subscriptions. Existing installations must accept new permissions. These GitHub mappings are not a guarantee for every GitLab field.

Older timestamped GitHub payloads cannot overwrite newer local edits. Repeated delivery IDs and remote comment identities prevent duplicate delivery effects. Compare remote and local timestamps when diagnosing conflicts; inspect provider events and operator logs for missed backfills. Turn off synchronization in the same owner-only setting to stop the configured sync; inspect existing imported work separately.

The demonstration repository is linked to GitHub. Issue synchronization is still off; inspect scope and existing backlog before enabling it. This capture does not prove a synchronized import.