LaTeX + Git: Version Control Without GitHub Lock-In
Git and LaTeX are a natural pair. A paper is plain text, plain text diffs cleanly, and version control gives you a real audit trail of who changed what and when. The trouble starts when your editor decides which Git provider you are allowed to use. LaTeX Git integration that only talks to GitHub is fine right up until your institution mandates a self-hosted GitLab, and then it is a wall. This article makes the case for provider-agnostic Git, walks through how it works in practice, and covers why that flexibility lines up neatly with EU data-protection requirements.
If you have ever wanted to push your manuscript to your university’s own GitLab server and found the option greyed out, this one is for you.
Why version control belongs in your LaTeX workflow
LaTeX source is text, so Git treats it the way it treats code. You get a commit history, branches for experimental rewrites, and the ability to see exactly what changed between two versions of a manuscript. For a long project like a thesis or a multi-author paper, that history is worth a great deal.
A typical workflow looks like this:
git clone https://gitlab.example.edu/lab/thesis.git
cd thesis
git checkout -b chapter-results
# write, compile, write
git add results.tex
git commit -m "Draft results section with new figure"
git push origin chapter-resultsNothing here is exotic. The catch is the host in that clone URL. If your editor only integrates with github.com, that GitLab URL is off-limits, and you are pushed toward a single commercial provider whether it suits your institution or not.
The GitHub-only problem
Several popular LaTeX editors integrate Git, but the integration is GitHub-only, often on the paid tier. That is a meaningful limitation for academic users, for a few concrete reasons.
Universities frequently run their own GitLab or Gitea instances, partly for control and partly for data governance. Many research groups already keep code on a self-hosted server and want the paper to live alongside it. And some institutions, especially in regulated fields, are not permitted to put work on a US-hosted Git platform at all. A GitHub-only integration ignores all of these situations.
The market leader, Overleaf, is a fair example here. Its Git integration on premium is GitHub-only, which works smoothly if GitHub is where you already are, and not at all if it is not. This is not a knock on the tool so much as a boundary you should know about before you commit a thesis to it.
Agnostic Git: bring any provider
inscrive.io takes the opposite stance. Its Git integration is agnostic: it works with any provider through a token or password flow, not just GitHub. GitLab.com, a self-hosted GitLab, Bitbucket, Gitea, your faculty’s internal server, all are fair game.
The mechanism is deliberately boring, which is what you want from infrastructure. You point inscrive at your repository and authenticate with a token, the same kind of personal access token you would generate for any Git host:
# Generate a scoped token on YOUR provider, then connect it in inscrive.
# Example: a self-hosted GitLab repo, no GitHub involved anywhere.
https://gitlab.internal.university.edu/research-group/manuscript.gitBecause the flow is provider-agnostic, the same steps work whether your host is a global SaaS platform or a box in your department’s server room. For an institution that has invested in self-hosted GitLab specifically to keep source code on its own infrastructure, this is the difference between an editor it can adopt and one it cannot.
How Git fits with live collaboration
Git is not the only way inscrive handles versioning, and that is worth being clear about. Day to day, the real-time collaborative editing and the built-in version history do most of the work. You edit together live, and you can rewind to any earlier version at any time without touching Git at all. We cover that in LaTeX version history and the best collaborative LaTeX editor for research teams.
Git integration sits alongside that for the cases where you want an external, institution-controlled record: syncing the manuscript to the same GitLab project as your analysis code, or keeping a canonical copy on a server your IT department backs up. The two approaches complement each other. Live history for the moment-to-moment work, Git for the durable, off-platform archive.
Why provider choice is a data-protection question
Here is the thread that ties Git flexibility to compliance. When you push your manuscript to a Git host, a full copy of your work lands on that host’s servers, in that host’s jurisdiction. If the only option is a US-based platform, then your unpublished research sits under US jurisdiction, with the EU-US transfer questions that Schrems II raised still unresolved for many institutions.
Provider-agnostic Git gives an EU research group a clean answer: push to a self-hosted GitLab on EU soil, or to an EU-based Git provider, and the data never leaves the jurisdiction. The editor stops dictating where your version-controlled copy lives.
That fits the rest of how inscrive is built. The editor itself stores all data on EU soil, hosted by Hetzner in Germany and Finland in ISO 27001-certified data centres, with no third-country transfers. There is a signed Data Processing Agreement and an independent audit report, and inscrive never uses your documents to train AI models. Pair that with Git that can target your own EU-hosted server and you have an end-to-end story where your manuscript never touches a jurisdiction you did not choose. More detail is on the GDPR page, and institutions can find central management options on the Organizations page.
Getting set up
You can use Git integration on inscrive’s Free tier, which also gives you up to 10 active projects, a 60-second compile window, unlimited collaborators, version history, and Zotero/Mendeley sync, with no credit card. The steps are short:
- Create or open a project in inscrive.
- Generate a personal access token on your Git provider of choice (GitHub, GitLab, self-hosted, whatever you run).
- Connect the repository in inscrive using that token.
- Push and pull as part of your normal workflow.
If you need more than 10 active projects or the longer 480-second compile window for a heavy thesis, Pro is €7/month (€5.83/month billed annually). The Git integration is the same on every tier, because provider choice is not the kind of thing worth putting behind a paywall.
A few patterns that work well
Provider-agnostic Git opens up workflows that a GitHub-only integration cannot. Here are a few worth borrowing.
Manuscript next to code. If your analysis lives in a GitLab project on your department’s server, put the paper in the same group, or even the same repository under a paper/ directory. Reviewers see the code and the write-up together, and there is a single place to clone. The figures your scripts generate sit right beside the LaTeX that includes them.
A faculty-controlled canonical copy. Some research groups designate one self-hosted repository as the source of truth, backed up by IT, with branch protection on the main branch. People draft live in inscrive and push labelled checkpoints to that repository when a section is done. The live editor handles the fast, messy work; the institutional Git server holds the durable record.
Mirroring for redundancy. Because the integration does not care which host it talks to, you can push to more than one. A primary on your university GitLab and a mirror elsewhere means a single provider outage never blocks you. This is harder to arrange when your editor only knows how to reach GitHub.
None of these are exotic, and all of them assume the one thing a GitHub-only tool denies you: the freedom to choose where your repository lives. A short checklist before you commit a long project:
- Does the editor let you point Git at an arbitrary host URL, not just one provider?
- Can you authenticate with a scoped personal access token rather than a full account login?
- Is the integration available on the tier you are actually on, or paywalled?
- Will your institution permit the host you intend to use, on data-residency grounds?
inscrive answers yes to the first three and leaves the fourth entirely in your hands, which is the point.
The point
LaTeX and Git belong together, but a Git integration that only speaks to one commercial provider quietly makes a decision your institution should be making. Agnostic Git hands that choice back. For an EU research group, that means the version-controlled copy of your work can live exactly where your data-protection rules require, which is usually not on the default platform.
Want Git on your terms? Connect any provider, GitHub or your own GitLab, on inscrive.io, free to start. See the plans on the pricing page.
