For writing the LaTeX document, here are several options I've seen used:
The "cleanest" and safest option is a git repository (on github or gitlab or bitbucket or, the good old way, on someone's server). Example with 3 authors. Example with 1 author (it's useful even then). Now, git isn't magic -- it will not guarantee that everyone writes in a common style, or that notations match; it will not resolve your disagreements about good writing; it also will not merge changes made in parallel to the same piece of the text (it will only alert you that such conflicting changes exist). But it removes various dangers such as losing your changes because your collaborator overwrites them, and it makes the history of the document readily available (though, in order to see the changes on github, your lines shouldn't be too long -- standard "mistake"). Also, branching allows you to experiment and make edits that your collaborators won't like until they see the final form, without raising the ire of your collaborators for (temporarily) messing up the work. I also found it very helpful when responding to referees -- with a clean history, I can easily list all my changes between two given dates. The biggest disadvantage of git is that people have to learn it (naturally, combinatorialists and computer scientists have the easiest time doing so), and that merge commits are confusing (I think, even to experts -- try debugging a merge gone wrong!).
A classical tactic, mentioned by @NikWeaver, is the "editing baton" (i.e., at each moment, at most one of the authors is editing the file, and the others are made aware that they should not be making changes; once done, the author emails the new version to all collaborators). I have seen it used a few times; my impression is that it works well when there are few authors and few changes to make and the "baton" doesn't change hands too often; but once things get complicated, it's a matter of time until confusion arises as to who is holding the "baton". Also, people forget to download the email attachments sometimes, or download them into the wrong place, etc. I cannot recommend this for projects where you foresee lots of editing.
The document is kept on the dropbox servers, in a folder that can be accessed and modified by all collaborators. This, per se, is not a safe strategy, since dropbox still allows people to overwrite each others' changes, and even when a conflict (i.e., two parallel changes by different authors) is spotted by dropbox, the way to resolve the conflict isn't particularly explicit (or is it now?). It is best combined with the "editing baton" to ensure that edits don't happen simultaneously. Also, make sure to have dropbox always running, to avoid situations where you edit the file but it stays local to your machine.
The federalist strategy: Each collaborator is in charge of their own well-delineated part (chapters or sections) of the work. Every once in a while, these parts are glued together into a draft. "Border-crossing" changes are made only when the authors come together (in meatspace or on IRC/skype/discord/whatever). This strategy works well when the project really splits into mostly self-contained parts; still, the result is likely to look heterogeneous.
I have never been involved in a project using Overleaf, so I can't comment on it. I suspect that it's somewhere between the github and dropbox workflows -- not as explicit as github, but you see each other making edits and thus can avoid stepping on each other's toes.
For a shared library of papers, a folder on dropbox will do.