By the end of this lesson you will be able to
- explain what version control is and why people who write anything at all need it
- tell Git and GitHub apart, and say what each one does
- describe the ideas of a repository, a commit and a branch in everyday words
- know what you will be able to do by the end of this course, and how the lessons work
The problem every writer meets
Suppose you keep the recipes for a small tea house in one document. On Monday you change the recipe for masala tea. On Tuesday you change it again. On Wednesday a customer says the Monday recipe was better. What do you do?
Most people solve this by copying the file. Soon the folder looks like this:
recipes.docx recipes-final.docx recipes-final-2.docx recipes-final-REALLY-final.docx recipes-monday-version.docx recipes-from-margaret.docx
This works for a week. After a month nobody knows which file is the latest, what changed between two of them, who changed it or why. If two people edit two copies on the same day, somebody must sit down and combine them by hand, and something is easily lost.
Every person who has worked on a document, a piece of code, a set of accounts or a thesis has met this problem. Version control is the cure for it.
What version control does
A version control system is a tool that keeps a complete, dated history of a set of files. You keep working on one copy of your files, exactly as normal. Whenever you reach a moment worth remembering, you tell the tool to save a snapshot, and you add a short note saying what you did. The tool stores the snapshot and never overwrites the earlier ones.
From then on you can:
- look back at how the project stood on any earlier day
- compare two snapshots and see exactly which lines were added or removed
- undo a change, or the whole project, back to a good state
- see who did what, and read their note explaining why
- try an idea safely on the side, and keep it only if it works
- combine the work of several people without one person overwriting another
Git was created for software, and programmers use it every day. But it works on any folder of files, and it is especially good with plain text: essays, notes, web pages, spreadsheets saved as text, configuration files. In this course we use small text files about tea, so you can concentrate on Git and not on programming.
Git and GitHub are not the same thing
Beginners often confuse these two names, so let us separate them at the start.
| Git | GitHub | |
|---|---|---|
| What it is | A program on your own computer | A website, at github.com |
| What it does | Records the history of your files, and lets you undo, compare and branch | Stores a copy of your Git history online, so you can share it, back it up and work with others |
| Needs the internet? | No. Almost everything works offline | Yes, it is a website |
| Who made it | Linus Torvalds, in 2005, for the Linux project | A company, in 2008. It is now owned by Microsoft |
| Is it free? | Yes, free and open source | Free for ordinary use; paid plans exist for large teams |
An easy way to remember it: Git is the filing cabinet in your own office. GitHub is a safe storage building in town where you keep a second copy of the cabinet, and where you can invite other people to look at it and add to it. There are other such buildings, such as GitLab and Bitbucket. They all use Git; only the building differs.
The four words you will hear all the time
Git has a small vocabulary. Here are the four most important words, in ordinary language. You will practise each one in the coming lessons.
| Word | Meaning | Everyday picture |
|---|---|---|
| Repository (or “repo”) | A project folder that Git is watching, together with its complete history | A ring binder holding your papers and every earlier draft of them |
| Commit | One saved snapshot of the project, with your note, your name and the date | A dated page in a diary: “14 March, changed the masala tea recipe” |
| Branch | A separate line of work that can grow without disturbing the main line | Photocopying the recipe book to try a new idea, with the option to merge it back if it works |
| Remote | Another copy of the repository, usually on GitHub | The second copy of the binder kept in the storage building |
A picture of a history
Below is what a small project's history looks like. Each circle is a commit, and time runs from the oldest at the bottom to the newest at the top, exactly as Git prints it. Do not worry about the commands; in Lesson 2.3 you will type them yourself.
$ git log --oneline d41c7a2 Add the chai masala recipe 9b0e1f5 Correct the price of Darjeeling tea 5a83c60 Add a menu of hot drinks f27d914 Start the tea notes
Each line is one commit: a short code that names it, and the note its author wrote. The code, such as 9b0e1f5, is how Git refers to that moment. You can go back to it whenever you like.
What you will learn
This course has ten modules. You begin with nothing installed and end by publishing a project on GitHub and taking part in a pull request.
| Module | What you will be able to do |
|---|---|
| 1. Getting Started | Use the command line, set Git up and make your first repository |
| 2. Saving Your Work | Stage and commit changes, read the status, browse the history and compare versions |
| 3. Undoing Things | Discard changes, fix the last commit, revert and reset |
| 4. Keeping a Project Tidy | Ignore files, remove and rename files, tag releases and understand how Git stores your work |
| 5. Branches | Work on separate lines and merge them, including resolving a conflict |
| 6. Working Tidily | Stash unfinished work, visit the past, cherry-pick and rebase |
| 7. Remotes | Push, pull, clone and fetch, and cope when a push is rejected |
| 8. GitHub | Use pull requests, forks and issues |
| 9. Careful Habits | Use sensible branching workflows, keep secrets out of a repository and recover from trouble |
| 10. Final Project | Publish a project of your own from start to finish |
How the lessons work
Learning Git from a book alone does not work, because Git is a skill of the fingers. So every lesson from 1.2 onwards has live practice terminals. Each one is a small pretend computer that runs in your browser. It has files, folders and a working copy of Git, and it behaves like the real thing, so what you learn here carries straight over to your own computer.
Next to each terminal you will see a picture of your project, updated after every command: the files and what state each is in, and the chain of commits. Watching the picture change is the fastest way to understand what Git is doing.
Each lesson has the same shape: a short lesson with examples you can try, five exercises that check your answer automatically, and a four-question quiz. Nothing you do in these terminals can harm a real computer, so experiment freely, and press Reset to start again whenever you like.
Only a web browser. Later, when you are ready to use Git on your own computer, Lesson 1.3 shows you how to install it. You will also need a free GitHub account for Module 8, and Lesson 8.1 walks you through creating one.
Quick check
Four questions to confirm the main ideas. Choose an answer to see the explanation.
Which sentence best describes version control?
Version control records snapshots of your files over time. That is what lets you compare versions, undo mistakes and see who changed what.
What is the difference between Git and GitHub?
Git runs on your own computer and works offline. GitHub is an online service built around Git, for sharing and backing up repositories.
In Git, what is a commit?
A commit is one saved snapshot. A folder that Git watches is a repository, and a separate line of work is a branch.
You want to try a risky new idea without disturbing your main work. Which Git feature is meant for this?
A branch is a separate line of work. If the idea succeeds you can merge it back; if not you can delete the branch and lose nothing else.
Summary
- Version control keeps a complete history of your files, so you can look back, compare, undo and work together.
- Git is the program on your own computer. GitHub is a website that stores a copy of your Git history online.
- A repository is a project folder Git watches, a commit is a saved snapshot, a branch is a separate line of work and a remote is another copy of the repository.
- Every terminal in this course is a safe pretend computer. You cannot break anything, so experiment freely.
Found a mistake on this page, or something unclear? Report a problem and mention “Git Lesson 1.1”.