Below is a record of the email sent to me by James Eagan on how to version control the Latex file for collaborative paper writing. I simply copy it here for my own record. Hope it will also be useful for you.

LaTeX is a great tool, especially for collaborative papers, but that only works when combined with a proper version control tool.  I’ve gone ahead and created a private git repository for the paper.  Please let me know your bitbucket username and I’ll go ahead and grant you access to the repository.  If you don’t already have an account, you can create one here:  <https://bitbucket.org/account/signup/?plan=5_users>.  Then you’ll be able to clone it from ssh://git@bitbucket.org:eaganj/XXX.

In Windows, in which case you’ll need to download and install the git commandline tool from here: <http://git-scm.com/download/win>.  (It ships with Mac OS.) 

I haven’t tried it, but there’s a GUI version here: <http://code.google.com/p/gitextensions/>.

I’m used to the command line, so I’ll describe the concepts in terms of what you would type on the command line, but they should apply to a GUI if you prefer.

Git maintains a complete copy of all of the history of everything in the repository.  We can use the bitbucket site as a central depot, our "master version".  You typically work on a local copy.  To create a local copy you need to clone the repository by connecting to the bitbucket server.  You can do so either via https or ssh.  I prefer ssh, because I can configure my keys such that I don’t need to enter my password each time.  If you want to take that approach, see <https://confluence.atlassian.com/display/BITBUCKET/How+to+install+a+public+key+on+your+bitbucket+account>.  To start playing around, you can just use the https version, knowing you’ll have to type your password each time you talk to the bitbucket server.

$ git clone https://sszhao26@bitbucket.org/XXX/XXX.git

This will create a local copy of the depot.  This is just a folder that you can rename, put wherever you want, etc.  Inside, it keeps a .git folder with all of the history.  You can just leave it alone.

Now, you can edit the files however you wish.  If you add a new file, you will need to tell git to keep track of it:

$ git add new-file-name

Once you have finished making your changes, you can commit them, specifying all of the files you’ve changed.  This basically adds an entry into the history timeline.

$ git commit changed-file another-changed-file

Or you can add all changed files with:

$ git commit -a

You will be asked to write a log message for the changes.

At this point, you have committed the changes to your local copy.  When you’re ready to share them with the depot, you need to ‘push’ them:

$ git push

Similarly, to retrieve any updates that anyone else has made, you can use:

$ git pull

This will fetch the changes pushed by others and merge them with your own.  To avoid conflicts, it’s best to avoid having two people edit the same part of the text at the same time.  If this happens, you’ll have to manually reconcile the two sets of changes.  If two people make changes to different parts of the file, git will usually be able to do the right thing automatically.

You will not be able to pull if you can any uncommitted changes.  You can check if you have any changes using:

$ git status

If you do, you can either commit them, then pull; or you can stash them aside for later:

$ git stash

Any time you have a clean local copy (that is, without uncommitted changes), you can restore your stash with:

$ git stash pop

It’s often useful to look at what you have modified in your local copy.  To do so, you can use the command:

$ git diff

Written by Shengdong Zhao

Shen is an Associate Professor in the Computer Science Department, National University of Singapore (NUS). He is the founding director of the NUS-HCI Lab, specializing in research and innovation in the area of human computer interaction.