LaTeX Collaboration Problems: Git Conflicts, Overwrites and Fixes

A paper with four authors is a distributed systems problem. Treat the source like a Word document passed around by email and someone will lose work; treat it like code, with one source of truth and a few rules, and it behaves. These are the seven failures that come up most when people write LaTeX together, what causes each, and the fix.

1. Overwritten work: two saves, one survivor

Symptom: Author A saves, author B saves a minute later from an older copy, and A’s afternoon is gone. Shared folders hide it behind a conflicted copy file that nobody opens. Cause: two people editing separate copies of one file. Fix: stop keeping copies. Either use Git, where an overlap becomes a visible conflict instead of a silent loss, or a real-time editor. LetX merges edits character by character through a CRDT (Yjs), not file by file, so two people typing in the same file never overwrite each other. How that sync works.

2. Git merge conflicts in .tex files

Symptom: every merge stops with a conflict, even when you and your co-author edited different sentences. Cause: Git compares lines, and a paragraph typed as one long line is one line. Fix: write one sentence per line. LaTeX ignores single line breaks inside a paragraph, so the PDF does not change, but each edit now touches its own line and most conflicts vanish. Split long documents into chapter files with \input or \include so people work in different files, and pull before you start writing.

When a conflict does happen, Git writes both versions into the file between markers:

We trained the model for 40 epochs.
<<<<<<< HEAD
Accuracy rose to 91.2\% on the held-out set (Table~\ref{tab:main}).
=======
Accuracy reached 91.2\% on the held-out set, see Table~\ref{tab:main}.
>>>>>>> alice/results
The gain over the baseline is significant.

Keep one side, or combine them, and delete all three marker lines. A forgotten marker does not stop the build: the file compiles and the markers are typeset into the PDF, where with LaTeX’s default font encoding the angle brackets even come out as ¡¡¡¡¡¡¡ and ¿¿¿¿¿¿¿. Run git diff --check before you commit, which warns about leftover conflict markers. Two settings make LaTeX diffs easier to read: git diff --word-diff shows changed words instead of whole lines, and a line *.tex diff=tex in .gitattributes turns on Git’s built-in LaTeX diff driver, which labels each change with the section it is in. To show a supervisor what changed as a marked-up PDF, latexdiff compares two versions of a .tex file and writes a third that typesets the insertions and deletions.

3. It compiles for one author and not the other

Symptom: the paper builds for Bob but fails for Alice, who gets an unknown command or a missing .sty file. Cause: different TeX distributions or years. MiKTeX installs packages on demand, TeX Live has a new release every year and updates packages through tlmgr in between, so two machines set up at different times can hold different versions of the same package. Fix: find the difference, then remove it. Put \listfiles on the first line of the main file: the log then ends with every file the document loaded and its version, and comparing the two lists usually shows the culprit in a minute. Better still, build in one shared environment. In LetX every author’s compile runs latexmk on the same full TeX Live 2025 on the build servers, so the paper builds the same way for everyone. See File .sty not found for the local fixes.

4. Figures that exist but will not load

Symptom: \includegraphics fails for everyone but the person who added the figure. Cause: usually letter case. macOS and Windows normally treat Plot.PNG and plot.png as the same file; Linux, which most servers and CI runners use, does not. The other usual causes are a figure that was never committed or uploaded, and a path written relative to a chapter file instead of the main file, which is where LaTeX resolves it from. Fix: lower-case file names without spaces, every figure in one figures/ folder, and \graphicspath{{figures/}} in the preamble. More in image not showing in LaTeX.

5. Preamble wars: macros and packages loaded twice

Symptom: after merging two people’s chapters, the build stops with Command \R already defined or Option clash for package xcolor. Cause: both authors defined the same shortcut, or loaded the same package with different options. Fix: keep the preamble and every shared macro in one file, such as macros.tex, owned by one person, and have chapters add nothing to it on their own. Load each package once with all the options it needs. If a class or another package loads it first, pass your options ahead of time with \PassOptionsToPackage before \documentclass. For a macro that may already exist, \providecommand defines it only if it is not defined yet.

6. Bibliographies that collide

Symptom: BibTeX reports a Repeated entry, or citations print as [?] after a merge. Cause: each author kept a .bib file, the same paper entered twice under two keys, or one key used for two papers. Fix: one shared .bib file for the project and one key format everyone follows, such as author, year and a title word. A reference manager helps; Zotero with the Better BibTeX plugin generates stable keys automatically, and the Zotero to LaTeX guide shows the setup. If citations still show as [?], work through undefined references, and agree early whether the paper uses BibTeX or biblatex (the difference), because mixing them fails in confusing ways.

7. A repository full of build files and data

Symptom: the repository is hundreds of megabytes because someone committed dataset_final.csv, and every pull brings someone else’s .aux files with it. Cause: nothing tells Git what not to track. Fix: commit only what the paper needs to compile, the figures exported as PDF or PNG included, keep raw data elsewhere, and ignore everything LaTeX generates:

# Files LaTeX and latexmk generate
*.aux
*.log
*.out
*.toc
*.lof
*.lot
*.bbl
*.blg
*.bcf
*.run.xml
*.fls
*.fdb_latexmk
*.synctex.gz
main.pdf

# Raw data the paper does not need to compile
data/

Stray .aux files from another machine are a common source of errors that are not in the source at all, so deleting them is the first thing to try when a build fails for no visible reason. In LetX the images sit in the project beside the .tex files and the build’s own files are kept apart from your project, so the paper is complete without the data behind it.

Git or a real-time editor?

Git is the better tool when the paper lives beside the code that produces its results, when every author already uses it, and when you want changes reviewed as pull requests. A real-time editor is better when co-authors include people who do not use Git, such as a supervisor who only comments, and when several people write in the same week. You can have both. LetX gives every project live editing, comments, Viewer, Commenter and Editor roles, and a version history per file, and on Pro a project can sync both ways with a GitHub repository, so the Git history covers every file, figures included. Text pasted from Word or a PDF brings one more problem, characters pdfLaTeX has no definition for, such as a typed ≤ or an invisible zero-width space; Unicode character not set up has the fix. For review marks in the PDF itself, see track changes and comments in LaTeX.