# Keep your Salesforce repository in step with the org.

> The SyncOnAI 360 GitHub connector, in beta, records deployed Salesforce changes in a GitHub.com repository. After a proposal deploys, the same metadata is committed to a new branch under your source path and a pull request is opened that links to the proposal and its receipt. It uses a token you scope to one repository.

Source: https://synconai360.com/connectors/github

## Key facts

- **1**: Commit per change, however many files
- **1**: Repository per token, scoped by you
- **0**: Routes into the org through Git
- **Beta**: Built and tested, early in live use

## Why the Salesforce repository drifts from the org

Teams that keep metadata in Git need the repository to match production. Every change made outside the Git flow, from Setup, a builder or an AI tool, makes the repository a little less true.

- **Changes outside Git.** Declarative changes deployed directly never reach the repository.
- **Reconciling by hand.** Someone retrieves metadata and commits it later, if they remember.
- **No link to the decision.** A commit does not say who approved the change or what was asked for.
- **Tools that want everything.** Git integrations often ask for broad access to every repository.

## What happens in GitHub when a Salesforce change deploys?

Once a proposal has deployed, the same metadata that went to the org is written to a new branch in your repository as one commit, under your source path, and a pull request is opened against your base branch. The pull request links back to the proposal and its receipt, so a reviewer can see the checks and the approval behind it.

Only changes that reached the org are committed. Pull requests can open automatically after each successful deploy, or be opened by hand from a deployed proposal.

- One commit per change
- Linked to the proposal and receipt
- Automatic or manual

## Can GitHub be used to change the Salesforce org?

No. The pull request is a record and a review surface, not a second route into the org. Every change still reaches the org through a proposal, with named checks, validation against the org and approval for production.

That keeps one governed path to production while the repository stays a faithful history of what was deployed.

- A record, not a route
- One governed path stays
- Repository mirrors what deployed

## How do you connect GitHub to SyncOnAI 360?

Create a fine-grained personal access token in GitHub, scoped by you to exactly one repository, and paste it with the repository name under Integrations, GitHub. Choose the base branch, or leave it to use the repository's default, and the source path, which defaults to force-app/main/default.

The token is stored encrypted, and you can revoke it in GitHub at any time without involving us.

- Token scoped to one repository
- Base branch and source path
- Revoke from GitHub

## How are branches kept tidy?

Every branch the connector creates starts with its own prefix. When you refresh the integration page, pull request states are updated, and branches whose pull requests are merged or closed are deleted.

Only branches this product created and recorded are ever touched. A branch with an open pull request, or one a person made by hand, is left alone.

- Its own branch prefix
- Cleanup on refresh
- Hand-made branches untouched

## What are the limits of the GitHub connector?

It works with GitHub.com only; GitHub Enterprise Server is not supported. Commits and pull requests are authored by the owner of the token. Deploy status is not written back to GitHub as commit statuses, and branch cleanup runs when someone refreshes rather than on a schedule.

The connector is in beta: it is built and tested, and early in live use with real repositories.

- GitHub.com only
- Authored by the token owner
- No status written back
- In beta

## How does a pull request help code review?

The pull request carries the same files the deploy used, written as one commit, so a reviewer reads the change the way they read any other code: file by file, in the team's usual review flow. Its description links to the proposal, with its named checks and blast radius, and to the receipt, with who approved it and when.

Teams that review code in GitHub keep doing so, while admin and AI-built changes reach the org through the governed path.

- Same files as the deploy
- Linked to checks and approval
- Your usual review flow

## Connecting GitHub

1. **Create a token.** Fine-grained, scoped to one repository.
2. **Connect.** Repository, base branch and source path.
3. **Deploy.** Ship a change through a proposal as usual.
4. **Review.** A pull request with the same files appears.

## The Salesforce repository, drifting versus in step

| Without | With SyncOnAI 360 |
|---|---|
| Declarative changes never reach Git | Every deployed change can open a pull request |
| Retrieve and commit later | The same files the deploy used |
| Commits with no context | Linked to the proposal and receipt |
| Broad access to every repository | A token scoped to one repository |

## Who uses the GitHub connector

- **Salesforce developers.** Keep the repository true to production while admins ship declarative changes through SyncOnAI 360.
- **Release managers.** Review deployed changes in the pull request flow the team already uses.
- **Technical architects.** Keep one history of the org in Git, with each change linked to its decision.
- **Consultancies.** Leave a client's repository matching what was delivered, change by change.

## Frequently asked questions

### Does SyncOnAI 360 deploy from GitHub?

No. Changes reach the org through proposals. GitHub receives a record of what was deployed.

### Does it support GitHub Enterprise Server?

No. GitHub.com only.

### Who is the author of the commits?

The owner of the token you supplied.

### Can pull requests open automatically?

Yes, after each successful deploy, if you turn that on. They can also be opened by hand.

### Is deploy status written back to GitHub?

No. The pull request records the change; it is not updated when the org changes again.

### Which branches does it delete?

Only branches it created, and only when their pull requests are merged or closed, when someone refreshes the integration page.

### Why is it in beta?

It is built and tested, and early in live use with real repositories. We would rather say so.

### Does it support Bitbucket or GitLab?

Not today.

### Is GitHub on every plan?

Yes. Every plan includes every feature.

### Which folder are files written to?

Your source path, which defaults to force-app/main/default, so files land where a Salesforce project expects them.

### Can we use our own branch naming?

Branches the connector creates always start with its own prefix, so cleanup can never touch a branch a person made.