This is the introductory lesson to version control using Git. It is assumed to be the very first thing done in a course.
Our philosophy is that we start from own local repository, branching and merging (locally), and a brief introduction to pushing to remotes. In the separate collaborative git lesson, we teach more use of remote repositories and good collaborative workflows. We try to stick to simple workflows, just enough for researchers who aren’t obsessed with git to be able to work well. We try to avoid commands which might get you into a bad state.
Our general flow is 10 minutes on “why version control”, followed by
about 45 minutes of the basics of how to make commits. Then, there are
several small steps until we get to branching, merging, and conflict
Then, we see a little bit about sharing repositories online, how to effectively dig into the history of a project, and a few other random points before we conclude.
The goals of the module as a whole are that the user will feel comfortable about staging changes, committing them, merging, and branching. The guacamole example that we use is inspired by Byron Smith, for original reference, see this thread. If you are teaching this lesson, see the instructor’s guide
If you are interested in the Git-aware prompt you can find it on GitHub.
In this introduction we will mention and use GitHub but also GitLab and Bitbucket allow similar workflows and basically everything that we will discuss is transferable. With this material and these exercises we do not endorse the company GitHub. We have chosen to demonstrate a number of concepts using examples with GitHub because it is currently the most popular web platform for hosting Git repositories and the chance is high that you will interact with GitHub-based repositories even if you choose to host your Git repository on another platform.
Why version control?
What is Git?
What is a repository?
How does Git operate?
How do I make commits?
How do I select what to commit?
|10:35||Using the Git staging area||
Why do we recommend to first add, then commit a change?
What should be included in a single commit?
|10:55||Undoing things||How can I undo things?|
|11:15||Branching and merging||
How can I or my team work on multiple features in parallel?
How to combine the changes of parallel tracks of work?
How can I permanently reference a point in history, like a software version?
How can we resolve conflicts?
How can we avoid conflicts?
|13:20||Sharing repositories online||
How can I set up a public repository online?
How can I clone a public repository to my computer?
How does version control scale from 1 to N users per repository?
How can we find out who introduced a line of code and when exactly?
How can we find out which commit broke or changed a functionality?
|14:15||Interrupted work||How can Git help us to deal with interrupted work and context switching?|
|14:30||Aliases and configuration||
How can I remember all these Git command options?
Is there too much configuration?
|14:40||Git under the hood||
Where are commits stored?
What are branches really?
|15:00||Start simple, later increase the level of complexity||
What level of complexity is necessary for each project?
Is one branch enough?