One of the main challenges in working with many people on a single project-- whether it’s planning and running multi-institution research initiative to collect and analyze data or the process of co-creating, sharing, and updating learning materials for your study group-- is “version control,” the task of managing the many contributions your group makes to shared working documents.
Your contributors may be spread around the world or working in the same room; they may be working simultaneously or asynchronously. No matter how your group is organized, the work of many contributors needs to be wrangled into a single project. Version control manages this process: it stores a history of changes and who made them, allowing you to revert or go back to earlier versions of those documents, and understand how contributions by different contributors have changed the project over time. You may have used word processing software that has a “changes,” “history” or “revisions” feature, which also allows you to see and revisit any changes to the document: this, too, is a form of version control. If you’ve never used GitHub or any other specialized version control software before, it may help to look at some diagrams and define some new terms before you get started.
When we code, write text, or create any kind of content using computers, we end up with a collection of files in a folder or directory, also known as a repository, or “repo.”
Even if you’re working alone, you’re probably going to make lots of changes to your content or code as you go-- you'll change some wording or functionality and leave others untouched, you'll make mistakes while you experiment with new ideas.
You might make multiple copies of your files to preserve a version that's working while you try to improve it or add functionality, but keeping track of all these versions and the differences between them becomes difficult.
You need version control. Imagine your document has a life story. Version control is like a time machine, it can take you back to the moment your document was born, or any other point in time when you or a collaborator saved that document. You don’t save copies of your document, you just save the the life story of the document, or its timeline.
What’s on the timeline? For our purposes, let’s call any saved change a commit. The life story of your document is a timeline of commits.
When we share and work on projects with collaborators, managing the changes, or commits that multiple collaborators working in different places at different times make to a single set of documents becomes very, very important.
And when we’re working with multiple collaborators, everybody needs to know and understand what commits are being incorporated into the repository and why, so good communication becomes very very important. The great news is that there’s a piece of version control software to help us both manage and communicate with our collaborators about commits to our project-- that software is called Git, and it’s the basis for GitHub, the platform your study group repository and website will live.