"Should we just use Git?" is the most common question in a lab that has outgrown email. The honest answer is that Git and a collaborative LaTeX editor solve different problems, and many teams do best using both.
This post compares them on the things that matter for a co-authored paper, and shows a setup that gets the benefits of each.
What Git is good at
Git was built for source code, and it shines when your paper behaves like code:
- Reproducibility. If your figures are generated by scripts in the same repository, one commit holds the code, the data and the paper that came from them.
- A permanent history. Every change is recorded and can be compared, tagged and restored, with no limit on how far back you go.
- Branches. Each author, or each big rewrite, can live on its own branch until it is ready.
- Automation. A CI job can compile the paper on every push and fail if it breaks.
- Ownership. The files live on your machines and your server, and no vendor is involved.
Where Git hurts for LaTeX
Git compares files line by line. LaTeX paragraphs are usually one very long line, so two edits to different sentences in the same paragraph count as a conflict. I reproduced this with a real repository, and I replay it step by step later this week; here is the short version.
Two authors edit different sentences in one paragraph:
We evaluate on three benchmarks. The model trains for ten epochs. Results are averaged over five seeds. One changes three to four. The other changes five to ten. Merging gives:
CONFLICT (content): Merge conflict in intro.tex Automatic merge failed; fix conflicts and then commit the result. Other costs:
- Everyone has to know Git. One co-author who has never used it becomes the bottleneck, or the person who emails a file back.
- Everyone needs a local TeX installation, or access to a build server, to see the PDF.
- No live view. You see a co-author's work after they commit and you pull, not while they type.
Where a collaborative editor is good
A live editor, such as Overleaf or LetX, removes the setup and the merge step:
- Simultaneous editing. Several people edit the same project at once and the edits merge as they type.
- No installation. A browser and a link are enough, so a new co-author joins in a minute.
- Instant PDF. Everyone compiles against the same TeX setup, so "it works on my machine" goes away.
- Low skill threshold. A senior co-author who only writes prose can contribute without learning a tool.
It has costs too. History may be shorter than Git's, depending on the plan. Limits on collaborators, compiles and build time depend on the vendor and the tier. And a live editor does not, by itself, give you reproducible figures or CI.
The decision table
| Your situation | Better fit |
|---|---|
| Figures and tables are generated by code in the same repo | Git |
| Co-authors have mixed technical skill | Collaborative editor |
| Several people write the same sections near the deadline | Collaborative editor |
| You need a permanent, auditable history | Git |
| You want CI that compiles on every change | Git |
| Fast onboarding of a new student or collaborator | Collaborative editor |
| Work must stay on your own infrastructure | Git |
A setup that uses both
You can keep the editor for writing and Git for the record:
- Write in the editor. Co-authors work on the text together.
- Sync to Git. Most editors offer some Git or GitHub link. LetX lists GitHub integration on its Pro and Academic Pro plans, and Overleaf lists integrations on its paid plans. Check each vendor's current plan page, since this changes.
- Keep code and data in the repository. The figures come from scripts, and the paper pulls them in.
- Tag the submission. Tag the commit you submit, so the exact source is recoverable years later.
If you stay with Git alone
Three practices make LaTeX much less painful in Git:
1. One sentence per line. Git then merges edits to different sentences without a conflict. I tested it on the same example, and the merge succeeded and kept both changes.
We evaluate on four benchmarks. The model trains for ten epochs. Results are averaged over ten seeds. LaTeX treats a single newline as a space, so the PDF looks the same.
2. A .gitignore for build files.
*.aux *.log *.out *.toc *.bbl *.blg *.fls *.fdb_latexmk *.synctex.gz 3. A diff you can read. latexdiff compares two versions and produces a marked-up source, which is easier to review than raw git diff. I cover it in tomorrow's post on track changes.
My view, and my bias
I work on LetX, a collaborative LaTeX editor, so weigh that. My honest read is that teams with mixed experience and tight deadlines usually write faster in a live editor, and teams whose papers are tied to code often want Git as the source of truth. Many want both. The free LetX plan allows unlimited collaborators, and its limits (40 compiles a day, the last 15 versions) are on the pricing page.
If you want the full checklist for choosing a tool, see the 9-point checklist.
Which does your lab use, Git, an editor, or both? Tell me in the comments.
