This book is Work in Progress. I appreciate your feedback to make the book better.

Version control, briefly

Somewhere on most hard drives there is a file called analysis_final.R, and next to it analysis_final_v2.R, analysis_final_v2_neu.R, and analysis_FINAL_really.R. Nobody remembers which one produced the figure in the report.

Git replaces that pile with one file and a history.

The thing you already know from Wikipedia

Every Wikipedia article has a View history tab, and almost nobody clicks it. Open it once and you find the article's whole life: one row per edit, each with an author, a timestamp, the size of the change, and a one-line summary of why. Tick any two rows and Wikipedia shows you exactly what changed between them, word by word. Nothing was ever overwritten. The article you normally read is simply the newest row.

That is version control, and Git gives your analysis the same three things:

Wikipedia Git
An edit, with a summary line A commit, with a message
The View history tab git log — or the History button in RStudio's Git pane
Comparing two revisions A diff
The article as it looks today Your working folder

Two differences matter. Wikipedia records a revision every time somebody saves; in Git you decide when a batch of work becomes a commit, which is why the message can be meaningful — "drop incomplete cases before the mass comparison" rather than "changes". And Wikipedia's history lives on one server, while a Git history lives inside your project folder, complete, in every copy of it.

So Git is not a backup. It is a camera pointed at your project, and you decide when it clicks.

Amazing Fact

That history tab is also a research tool, and it comes back in Chapter 3.1, where we scrape a Wikipedia table of the most expensive paintings ever sold.

A scraped table is a snapshot of one revision. The history tells you whether the number you just put in your analysis has stood unchanged for three years or was edited last Tuesday by an anonymous account, and whether the talk page shows a dispute about it. A figure with a stable history and a figure with a contested one are not equally good evidence, even though they look identical once they land in your data frame.

Provenance is not a footnote. It is part of the measurement.

GitHub is also a library

GitHub (or GitLab, or Codeberg) is a copy of a Git history on someone else's server. It gives you an off-site copy, a way to work with others without emailing files, and a place to publish. This book lives on GitHub; the page you are reading was built from it, and every sentence in it has an author and a timestamp.

But most people's first useful encounter with GitHub involves no programming at all. It is where researchers and instructors put their material, and you can simply take it.

Here is a real example — a GESIS workshop on collecting and analysing YouTube comments, by Johannes Breuer, Julian Kohne and M. Rohangis Mohseni:

https://github.com/jobreu/youtube-workshop-gesis-2022

The repository holds slides, scripts, exercises and solutions, released under a Creative Commons licence. Nothing there needs to be written by you. Three ways to get it onto your machine, in increasing order of usefulness:

  1. Download ZIP. The green Code button on the repository page. No Git, no account, no command line. You get the folder; you do not get the history, and you will not notice when the author fixes an exercise.
  2. Clone it into an RStudio project. File → New Project → Version Control → Git, paste the repository address, choose a folder. This needs Git installed, and gives you a real project you can update later with one click on Pull.
  3. From R, if you use usethis:
usethis::create_from_github("jobreu/youtube-workshop-gesis-2022",
                            destdir = "~/courses")

Notice what you get in this particular case: the folder contains a youtube-workshop-gesis-2022.Rproj file. Open it and every relative path in every script works immediately, because the author organised the material as a project — the same habit from the previous section, arriving as a gift.

One courtesy and one caution. The courtesy: material like this is usually licensed, so check the LICENSE file and cite the authors when you reuse a slide or a script. The caution: a repository is somebody's working folder, not a published article. Code you download is worth reading before it is worth running.

Your own history

The everyday loop is three steps, and RStudio has a Git pane with three buttons for exactly them:

  1. Stage the files you want to record.
  2. Commit them with a message that says why, not what.
  3. Push to send the commits to GitHub.

One file deserves attention from the first day. .gitignore lists everything that must not be recorded:

data/raw/*.dta      # licensed survey data — never leaves this machine
.Rhistory
.RData
output/
*.log

For social science this is not housekeeping, it is data protection. Survey micro-data, administrative records and anything with personal information belong in the ignore list, and a commit that once contained them is difficult to erase. Commit the code that produces results; publish the data only when you are allowed to.

Is it worth it for a solo project? Sometimes not. For a single script written in an afternoon, an RStudio project and a sensible folder are already most of the benefit. Git pays from the moment a project has a future: a thesis, a paper you will revise, teaching material you reuse each year, or anything two people touch.

And it closes the circle this chapter opened. Why code? argued that a result is only as good as the trail that leads to it. Version control extends that trail backwards in time: not just how this number was produced, but when the recipe changed, and why somebody thought that was a good idea.

Reading

Happy Git and GitHub for the useR by Jenny Bryan is the gentlest path from zero to a working setup, including the part everyone gets stuck on — authentication.