Version control is the lab notebook of the digital world: it’s what professionals use to keep track of what they’ve done and to collaborate with other people. Every large software development project relies on it, and most programmers use it for their small jobs as well. And it isn’t just for software: books, papers, small data sets, and anything that changes over time or needs to be shared can and should be stored in a version control system.
Version control is better than mailing files back and forth because:
Nothing that is committed to version control is ever lost. Since all old versions of files are saved, it’s always possible to go back in time to see exactly who wrote what on a particular day, or what version of a program was used to generate a particular set of results.
As we have this record of who made what changes when, we know who to ask if we have questions later on, and, if needed, revert to a previous version, much like the “undo” feature in an editor.
When several people collaborate in the same project, it’s possible to accidentally overlook or overwrite someone’s changes: the version control system automatically notifies users whenever there’s a conflict between one person’s work and another’s.
Teams are not the only ones to benefit from version control: lone researchers can benefit immensely. Keeping a record of what was changed, when, and why is extremely useful for all researchers if they ever need to come back to the project later on (e.g. a year later, when memory has faded).
This lesson shows how to use
a popular open source version control system called
(also known as
It is widely used,
both because it’s easy to set up
and because of a hosting site called Bitbucket.
No matter which version control system you use,
the most important thing to learn is not the details of their more obscure commands,
but the workflow that they encourage.
Students should understand how to interact with the Unix shell (e.g., how to change their working directory) before beginning this lesson.
|Setup||Download files required for the lesson|
|00:00||1. Automated Version Control||What is version control and why should I use it?|
|00:15||2. Configuring Mercurial||How do I get set up to use Mercurial?|
|00:30||3. Creating a Repository||Where does Mercurial store information?|
|00:45||4. Tracking Changes to Files||
How do I record changes in Mercurial?
How do I check the status of my version control repository?
How do I record notes about what changes I made and why?
|01:00||5. Making Changes||How can I change files in a repository?|
|01:15||6. Exploring History||
How do I review my changes?
How can I recover old versions of files?
|01:30||7. Recovering Old Versions||How can I recover old versions of files?|
|01:45||8. Ignoring Things||How can I tell Mercurial to ignore files I don’t want to track?|
|02:00||9. Remote Repositories||How can I use Mercurial to store information on other machines?|
|02:15||10. Working with Clone Repositories||How can I make local copies of repositories to work in?|
|02:30||11. Collaboration||How can I control who can see my work?|
|02:45||12. Merging Changes from Different Clones||How do I combine changes made in different repositories?|
|03:00||13. Merge Conflicts||What do I do when my changes conflict with someone else’s?|
|03:15||14. Open Science||How can version control help me make my work more open?|
|03:30||15. Licensing||What licensing information should I include with my work?|
|03:45||16. Hosting||Where should I host my version control repositories?|
The actual schedule may vary slightly depending on the topics and exercises chosen by the instructor.