Version control Part 1: Local repository

Previously I talked about setting up a project directory. Now I’ll run through the first stages of something I see as an integral part of reproducible research: version control.

Why version control?

Loosely, think of “version control” like track changes in Word but for all the (plain text) files in your project directory. More formally, a version control system is a piece of software that will automatically detect when files in monitored directories change, record which lines of the file changed and how, prompt you to comment why you changed the file, then have you “commit” the changes to a repository (a data bank containing the history of the project directory). If you’re collaborating on the project with others, the version control system can be used to make sure each collaborator’s files stay up to date with each other, record who changed what, and notice if two people changed a file in conflicting ways (you’ll then be asked to look at the changes and decide which to keep). This is a big advantage over something like sharing a folder on Dropbox. You can even use a version control system to keep different versions of the same project (using “branches”). Finally, from the perspective of making your science open and reproducible, making the version control history of the project available is close to a gold standard. Not only do users get the version that created the final results, but if they’re so inclined they could search back through your repository history to see how the project evolved. Being able to just switch a repository from private to public also makes it really simple to share your code (say, when the paper comes out). Plenty of other people have written about the usefulness of version control for scientists (see here, here and here, for example), so in this post I’m going to concentrate on the way I use it.

How I set up version control

First, a disclaimer: I am not a version control expert. I use simple tools, and so far they’ve worked for me. Any problems I’ve had I’ve been able to resolve with some Googling and Stack Overflow. In the remainder of this post I’ll show you how I set things up, in the hope that this will be useful to you. Second disclaimer: I use OSX (and a bit of Linux on experimental machines), so my process might have some OSX-specific steps. However, all the software I’m using is cross-platform, so you should be able to port the process to your operating system of choice with a bit of internet searching.

The specific version control software I use is git. I find this to be the simplest system I’ve tried, with the best support for integrating with others and publishing your code. You can do some tutorials and get more info at the git site, or watch this video. I mostly use git through a GUI (graphical user interface) rather than through the command line because I find this simpler for day-to-day work. I use the Github GUI, which you can download here for mac and here for windows. I have found that this does everything I regularly need, in a clean and simple interface. Other people (Diederick, posting on this blog) have recommended SmartGit, which seems more fully-featured and is free for academic use. I haven’t tried this yet, though. So, without further ado, here are the steps for setting up version control in the way I have.

  1. Download and install the Github GUI for your operating system of choice. You might need to create a Github account at this stage (which I would recommend doing anyway). Since I already have everything installed on my setup here, I’m not going to walk you through this stage. It should be well-explained by the app itself, but if there are other steps you need to take, post them in the comments below and I will update this post.

  2. Now open the Github application. We’re going to use this to create a new repository for a new project. I will use the project directory structure I set up before:


In the OSX Github GUI, go to the small plus sign in the lower left corner of the main display and select “Create New Repository”:


Select the root directory of your project (in my case, this is called blog_example). Now we have this blank screen for our new repository:


The Github GUI has created a new git repository, which lives in a hidden directory within our parent directory. Here you can see the contents of the directory before and after I created the repository:


Note how the second call to ls -la has revealed a new (hidden) folder .git. This contains all the files for the git repository, and is what the Github GUI uses. Note that it’s just a normal git repository, so if you want to do something that isn’t possible in the GUI, you can just interact with the repository using the command line.

Now let’s create a file in our project directory. I made a file in the root directory called master_manuscript.txt, with two lines of text. When we flip back to the Github GUI, we see that it has detected the new file:


I enter a commit message “created master file”, hit commit, and there you go. Our git repository has its first local commit:


Note how the commit is listed in “Unsynced Commits”. It’s “Unsynched” because our local repository hasn’t been synchronised with a remote repository, such as one on Github. That’s fine if you just want to maintain a local repository for yourself. I will discuss synching with remotes in a future post.

Now let’s try modifying the file master_manuscript.txt. I’m going to delete the original two lines and add something new. How about a Well Thought-Out Englilsh Paper?


The GUI shows us which lines were deleted (in red) and which were added (green). We can commit this new change, then take a look at our project’s history (in the history tab):


There we can see our original commit (“created master file”) as well as our new one. On second thought, Strong Bad’s Well Thought-Out Englilsh paper is maybe not so well thought out. Let’s revert to the last version. Select our commit “a well thought-out englilsh paper” and click on the gear to the right of the panel, then select “Revert This Commit” (for the difference between revert and roll back, see here). We then get a new commit, telling us that we’ve reverted the content of the file back to the old one:


If you open up the file master_manuscript.txt, you’ll see that it has been changed to have the original two lines by git.

Ignoring files

Let’s say that we now have some files in our project directory that we don’t want git to monitor (e.g. a really large data file that would be infeasible to upload to a remote repository). We can add this to the list of files to be ignored by placing it in the file .gitignore. The GUI allows us to do this by right clicking on a file when it appears on the left pane and selecting “ignore”. You can also ignore entire directories by entering them into .gitignore. You can do this in the GUI by going to the Settings pane, to the ignored files section, and entering a line like:


The GUI simply adds this line to your .gitignore file.

I usually ignore the /out and /figs/ directories since their contents can be regenerated from your code, and for some of my analyses the contents of /out can be rather large.


A branch is basically an independent copy of a state of the respository that allows you to do work in parallel to other changes occurring to the repository. While it’s aimed more at larger collaborative projects, I have found it useful in working on solo repositories as a way to explicitly maintain old versions of analyses or papers. I will cover branching more in a future post.

Other things to note

Note how in the explanation above I said “for all the (plain text) files in your directory”? A plain text file is something that looks ok when opened in a text editor like notepad. They could have extensions like .txt, .csv, .m, .R, .py, .tex, etc, but they are still readable in a text editor. Version control works beautifully for these. However, binary files not so much. You won’t take the most advantage of version control if you try to keep track of something like Word docs, .pdf or .jpg. At best your version control will be able to record that the file changed – but not which lines. On the other hand, it may still work to keep collaborators synched with the latest file, but conflict resolution would be hard.

A final disclaimer: Like any file, keeping your git repository within a Dropbox folder carries the risk that the file could be corrupted. Specifically, if you work from computer A, make changes, shut down that computer before Dropbox finishes syncing, then subsequently work on the same files from computer B, you will have conflicts when you open up computer A again. Keep a separate backup of your Dropbox folder (e.g. with Time Machine, or Dropbox’s own file history service) to prevent anything nasty happening. This also becomes less of a problem if you are pushing your git repository to a remote server, which is what I will cover in the next post.

UPDATE 12 Feb 2014:

A few people have commented to me on other forums about my selection of git over something else. Specifically, a lot of people find git to be unnecessarily complex for many projects as compared to say, subversion.

Alex Holcombe shared the following: “I have started using github (inside Rstudio), and seems to be working, but after reading this I am very afraid”

Another friend writes: “SVN makes perfect sense to me (I used it in my programming jobs) and would definitely do the trick. Git on the other hand is a brutally complicated, confusing thing, (e.g. that will require hours to master even for relatively simple tasks. However it is widely in use out in the world of software development, so the skill is a valuable one to develop, and has some super neat features (all that branching). ”

I guess my response to these concerns is just to say that the above is how I’ve done version control, and so far it has worked for me. However, the vast majority of what I’ve done so far is single-user repositories (i.e. just me), where I integrate changes and comments of co-authors myself manually. Perhaps I will learn to hate git when I have to do more with other contributors, but for now the workflow above works for me.


  1. Tom,

    This blog’s great–again, keep at it.

    My only concern about your approach is that the learning curves for many of the programs involved are quite steep. Though I may have time to hack my way into the thicket of R and Latex, my supervisors don’t–most of them therefore still use Word and proprietary statistics software. The same often seems to be true for journal review boards (e.g., they request submitted manuscripts in .doc form, etc).

    Would you consider doing a post about how you’ve managed to smooth the integration of your methods and tools with more traditional ones?

    1. Hi Dylan, good point. Basically, integrating my document process with a word doc is a pain – but then, there’s nothing stopping you from using Word for the writing. I’ve done the LaTeX -> Word conversion for a journal that required submissions as .doc. Essentially I kept the whole thing as LaTeX until the journal wanted the final upload (i.e. after it was accepted). I see reformatting manuscripts using journal templates prior to acceptance as a complete waste of time (aside from using the sections the journal wants). I’ll reformat the manuscript after it’s accepted, not for each submission to a new journal (because of the potential for rejection and then the need to reformat). Every journal I’ve encountered allows you to upload a pdf in the submission stage (to be sent to reviewers).

      As for collaborators: yes, some of this stuff requires your collaborators to get on board to some extent. What I’ve done with documents and version control so far for collaborators who don’t want to use .tex and git is to have them modify the .tex file (you can read it in notepad or whatever you like), then send me their modified file and I integrate their comments using a diff function (specifically, the one in TextWrangler). This is simple enough. For those who didn’t even want to edit a text file, they commented on a pdf version and I manually integrated these.

      Obviously, imposing a different process on others requires tact, and I would do so explaining the benefits (and only on a project where I’m lead author, and thus in control). I accept that some people may have co-authors or supervisors who are not as tolerant as the ones I’ve been lucky to have. That sucks, but I guess all you can do is make a case for the benefits of spending some time learning at least enough to integrate with your approach (you take care of all the other stuff, that allows them to publish a cool reproducible project!).

      While document writing will be hard, I see analysis as easier. You could go do your analysis in R or whatever, which your co-authors can replicate by running your scripts if they like (because they can install R easily for free!). They could even check your analyses in their package of choice.

      So the short answer to your question is: if you want to use all the things I use, the integration with more traditional tools is not smooth, and there are few ways around this. We can only try to honestly give an account of the advantages of these tools, and encourage people to give it a try. As for journals, many journals (including all the PLoS journals, JoV, etc) do accept final submissions in .tex. For those that don’t, I just send an email after acceptance saying “please consider accepting manuscripts in .tex”.

Comments are closed.