GitHub sync

Connect a project to GitHub and Vorx keeps your app's code in a private repository you own. Every edit Vorx makes lands there as a commit, so your project has a real version-controlled home outside Vorx — one you can clone, review, or hand to a developer.

This is separate from version history, which is Vorx's own checkpoint trail. You don't need GitHub to roll back a change.

Connecting takes two steps

1. Add a connection. Authorize the Vorx app on a GitHub account or organization. This is a one-off per account, and you can add more than one — a personal account and your company's organization, say.

2. Connect the project. Pick the account, choose a repository name, and Vorx creates the repository and makes the first push.

Vorx always creates a brand-new private repository, one per project. You don't point a project at an existing repo, and Vorx never pushes to a repository it didn't make.

Connecting, disconnecting and reconnecting need project or workspace owner or admin access — see roles and permissions.

What gets pushed, and when

After each successful edit, Vorx pushes the project's current files to the active branch as a single clean commit, co-attributed to whoever asked for the change. There's no button to press; a finished edit is a commit.

Vorx pushes when an edit succeeds. An edit that failed, or one you rolled back, doesn't leave a commit behind.

When a push can't go through

If the active branch has commits Vorx hasn't seen — someone pushed directly, or a branch protection rule rejected the write — Vorx will not force its way over your work. It pushes to a timestamped side branch instead, named vorx-sync-<timestamp>, and tells you in Settings → Git.

Nothing is lost when this happens, but the two histories have diverged. Merge the side branch, or switch Vorx to a different active branch, and normal pushes resume.

Changes you make on GitHub

The integration is designed to work both ways on the active branch: commits you push to GitHub are meant to flow back into your Vorx project.

Check that it is actually working for you before you rely on it. Receiving pushes back depends on the Vorx deployment being able to accept events from GitHub, which is a platform-level setting rather than something a project can turn on. When it isn't working, Settings → Git shows a notice saying "Changes made directly on GitHub will not reach Vorx", and you should treat the repository as a one-way mirror: edit in Vorx, read on GitHub. Reconnecting the project will not change this — the notice is telling you about the deployment, not about your project.

If you don't see that notice, pushes to the active branch are picked up. Commits on other branches are ignored by design, and a push that arrives while a build is running is picked up once the build finishes.

Branches

One branch is the active branch — the one Vorx pushes to and pulls from. You can create a branch from Settings → Git or switch the active branch to an existing one, which is the clean way to try something without touching your main line.

If the active branch is deleted on GitHub, Vorx switches to a fallback branch rather than failing every push, and says so.

Recent activity

Settings → Git keeps a log of what the integration has done: pushes out, pulls in, pushes diverted to a side branch, commits skipped for being on another branch, and connection changes. When something looks out of step, this is the first place to look — a missing entry is as informative as a failed one.

Disconnecting

Disconnecting removes the link between the project and the repository. Your GitHub repository and everything in it stays — Vorx does not delete it, and you keep full access.

Reconnecting afterwards creates a new repository rather than re-adopting the old one. If you want the original repo back in the loop, keep the connection rather than disconnecting.

Next steps

• Version history and rollback — Vorx's own checkpoints, which work with or without GitHub
• Collaboration — bringing other people into the project itself
• Roles and permissions — who can connect and disconnect
• Deploying — publishing is separate from pushing code