Git integration

Account and server required

The project and folder Git operations on this page run on the server. You need project permissions and access to the destination repository.

Choose the right Git workflow

Starting point	Use
You want to back up your account’s package and font libraries	Library backups with the CLI, using Git on your computer
Your paper is already in Tylor	Publish to Git in the editor, with a new empty repository
Your source is already in a repository	From Git on the dashboard
You want an archive of a whole research or teaching folder	The folder’s Backups… action, then its optional Git destination

Project Git sync is useful when a coauthor uses a local editor, a lab keeps source in Git, or a document needs to travel with a code repository. It synchronizes project files, not all account data.

Publish the paper you are writing

1. Open Account → Advanced → Git connections and connect GitHub, GitLab.com, or your organization’s GitLab. An administrator must first enable the provider. This connection is separate from signing in to Tylor.
2. Open your paper and select Publish to Git in the editor header.
3. Choose Create repository, select the connected account and owner/group, and enter a repository name.
4. Keep Private selected unless you want anyone to read the files and pushed history. Choose Create private repository & push and wait for confirmation.

Repository access uses the permissions shown by your Git host. GitHub authorization includes public/private repositories and organization membership; GitLab requests API access. Group policy may still restrict creation. Tokens stay encrypted on Tylor’s server and refresh automatically.

If the first push fails after creation, the repository remains linked: use Commit & push to retry. If creation itself times out, your Tylor document stays safe. Check your Git host before trying again; if an empty repository exists, link its URL. Tylor stops automatic creation retries when the result is uncertain.

Link a repository by URL

1. Create an empty repository at your Git host. Do not initialize it with a README or other files.
2. Connect a repository account as above, or open Account → Advanced → Git connections → Access tokens and add a token with write access.
3. Open your paper and select the Git branch icon in the header, titled Publish to Git.
4. Choose Link by URL and enter the HTTPS repository URL and branch. Use a subdirectory only if you intentionally want the document under a path inside the repository.
5. Select the saved credential, or use the access-token field if appropriate, and link the repository.
6. Enter a meaningful commit message, author name, and author email, then choose Commit & push.

The screenshot shows setup with an example URL; it is not a repository to connect to. Use your own destination. Keep tokens in the credential controls, never embedded in the URL or your Typst source.

For the sample paper, a useful message would be Clarify the two-pass review protocol. Wait for Tylor to confirm the push and inspect the destination repository.

Pull and push during revisions

Wait for pending edits to sync before either operation. Tylor stops browser Git operations when queued work remains because the server must have the saved files being synchronized.

Pull replaces project files with the remote branch after preserving a server History checkpoint. Read the confirmation and protect any work you need before proceeding. After a pull, follow any update notice in open editing sessions and inspect the compiled paper.

Commit & push sends your saved project files. If the remote changed since the last sync, inspect and reconcile those changes before retrying. Do not bypass that situation with force push.

Keep a separate submission record

A Git commit records a source revision. A submission snapshot preserves the exact captured PDF and source archive that left the team. Use both when your workflow needs both records.

Project sync does not back up sharing, review records, account credentials, or the whole font/package library. For a set of papers, reports, or revision sheets, use the folder archive workflow and check its capture scope.

Server connection restrictions

Use the canonical HTTPS clone URL on port 443. Server Git refuses redirects and hosts resolving to loopback, private, link-local or other non-public addresses. This also applies to Git folder backups. Public self-hosted Git remains supported; private-network Git servers are not supported by this server transport. Local CLI library backups use your own local Git configuration separately.

Transfers are limited to 64 MiB of received data and a 90-second transfer budget, with shorter connection/read timeouts. Large histories may exceed the limit even when the current document is small. Failures preserve the existing saved document; inspect the remote before retrying an uncertain push. Do not put passwords or tokens in clone URLs.

The server processes one Git repository job at a time. If it reports that processing is busy or unavailable, wait briefly and retry. After any uncertain push, check the Git host first: the remote may have accepted a commit even if Tylor did not receive its confirmation.

Reconnect after a credential reset

An administrator may clear saved repository access after a security rotation. Existing project links and their last synced revision remain, but private repository pull and push pause until access is restored. Open Account → Advanced → Git connections and reconnect the same GitHub or GitLab account. If you used an access token, revoke the old token at your Git host and add a replacement under Access tokens. A project linked with a directly entered token must be unlinked and linked again with the replacement token; check its repository URL, branch, directory and last synced revision before doing so. Public repositories may continue to pull without a token.