One Shared .bib File for Co-Authors Without Merge Pain

The bibliography is the file everyone touches and nobody owns. Three co-authors add references in their own style, the same paper enters twice under different keys, and two people append an entry to the end of the file at the same moment, which is exactly where merges collide.

Five rules prevent most of it. I ran the BibTeX examples below to confirm the messages.

Rule 1: one .bib file, in the shared project

Keep a single refs.bib next to main.tex. Do not let each author keep a private copy and paste entries in later, because that is how the same paper ends up with three different keys.

Rule 2: one key format, for everyone

Agree a pattern and write it down. A common one is first author's surname, year, and a keyword from the title:

vaswani2017attention
devlin2019bert
he2016deep

A fixed pattern means a co-author can guess a key without opening the file, and two people are less likely to add the same paper under different names.

Rule 3: format every entry the same way

One field per line, the same indentation, and a trailing comma on every field line:

@article{vaswani2017attention,
  author  = {Vaswani, Ashish and Shazeer, Noam},
  title   = {Attention Is All You Need},
  journal = {Advances in Neural Information Processing Systems},
  year    = {2017}
}

With one field per line, a version-control diff shows exactly which field changed. In a live editor it makes entries easy to scan. Consistent formatting also makes duplicate entries easier to spot by eye.

Rule 4: keep entries sorted by key

If everyone appends to the end of the file, two people adding entries at the same time touch the same spot. Sorted entries spread the additions across the file, so different people usually edit different places. Reference managers and tools such as BibTool can normalize and sort a .bib file, so you do not have to do it by hand.

Rule 5: check before you submit

Two checks catch the most common problems, and BibTeX tells you about both.

Duplicate keys. If the same key appears twice, BibTeX stops at the second one:

Repeated entry---line 7 of file refs.bib
 : @article{vaswani2017attention
 :                              ,
I'm skipping whatever remains of this entry

Missing fields. If an entry lacks a field the style needs, you get a warning:

Warning--empty journal in a2020x

Run BibTeX and read its output as part of the pre-submission check. Do not rely on the PDF alone, because a missing field can leave a reference half-formatted without any visible error.

What about a reference manager?

If your team uses Zotero or a similar tool, you can export to .bib and keep the library as the source of truth. Zotero's Better BibTeX add-on can keep an exported file updated automatically; check its documentation for the current setup. The trade-off is that the file is now generated, so edit entries in the manager, not in the .bib, or the next export will overwrite your change.

Pick one source of truth, either the manager or the .bib, and tell everyone which it is.

A short policy to paste in your lab notes

1. All references live in one refs.bib in the project.
2. Keys follow surname + year + keyword.
3. One field per line, entries sorted by key.
4. Before submission, one person runs BibTeX and clears every warning.
5. If you use a reference manager, edits are made there, not in the exported file.

If your team writes in a shared editor

A shared .bib is easier when everyone edits the same project, since there is one copy to fix. I work on LetX, a collaborative LaTeX editor with unlimited collaborators on its free plan, and these rules apply there as in any other setup. The free plan has limits such as 40 compiles a day.

Next in this series: a merge conflict in a .tex file, replayed step by step. This post is part of the series on collaborative research writing.

How does your team handle references? Tell me in the comments.