Imagine you are working on a coding project with a friend and you both need to work on the same files. If you take turns, each of you will waste time waiting for the other to finish, but if you work on your own copies and email changes back and forth things will be lost, overwritten, or duplicated.
A solution to this problem is to use version control to manage your work. Version control is better than mailing files back and forth:
Nothing that is committed to version control is ever lost, unless you work really, really hard at it. 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).
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.
Prerequisites
In this lesson we use GitHub from a web browser and Git from the Unix Shell. Some previous experience with the shell is expected, but isn’t mandatory.
| Setup | Dowload files used on the lesson. | |
| 00:00 | 1. Automated Version Control | What is version control and why should I use it? |
| 00:05 | 2. Setting Up Git | How do I get set up to use Git? |
| 00:10 | 3. Creating a Repository | How can we create a new Git repository |
| 00:20 | 4. Tracking Changes |
How do I record changes in Git?
How do I check the status of my version control repository? How do I record notes about what changes I made and why? |
| 00:50 | 5. Pushing and Pulling to and from GitHub | How do I share my changes with others on the web? |
| 01:10 | 6. Ignoring Things | How can I tell Git to ignore files I don’t want to track? |
| 01:30 | 7. Collaborating | How can I use version control to collaborate with other people? |
| 02:25 | 8. Conflicts | What do I do when my changes conflict with someone else’s? |
| 02:55 | 9. Forks and Pull Requests | How do I contribute to repositories I have not been given permission to modify? |
| 03:25 | 10. Open Science | How can version control help me make my work more open? |
| 03:35 | 11. Licensing | What licensing information should I include with my work? |
| 03:40 | 12. Citation | How can I make my work easier to cite? |
| 03:42 | 13. Hosting | Where should I host my version control repositories? |
| 03:52 | 14. Using Git from RStudio | How can I use Git with RStudio? |
| 04:02 | Finish |
The actual schedule may vary slightly depending on the topics and exercises chosen by the instructor.