Student Search Per-Arne's Git Good!
Menu for Per-Arne's Git Good!
Courses and project Per-Arne's Git Good!

Why Git? Git, GitHub and distributed version control

Module 1: Foundations · 10 min

The interactive lesson needs JavaScript. The text below is the complete lesson.

After this lesson you can

  • explain the difference between Git, the program that creates and stores the history, and hosting services such as GitHub, GitLab and Bitbucket understand
  • compare file sync such as Dropbox, centralised version control such as SVN and distributed version control such as Git by where the history lives and what survives when the server disappears analyse
  • restore a project on a new server from a clone after the old server is gone apply

Understand: Where does the history live?

Every project changes daily, and usually several people take part. You then need answers to three questions: What did it look like before? Who changed what, and why? And how do we combine work done at the same time? That is what version control answers. What matters most is where the history lives.

Dropbox, OneDrive and Google Drive synchronise files. Everyone gets the newest version of each file, and the service keeps older versions of each file for a while. But there is no history of the project as a whole, and no message saying why something changed. If two people save the same file at the same time, you get a conflicted copy instead of a merge.

Centralised version control, such as Subversion, often called SVN, has a real history with commits and messages. But the history lives only on the server. You have a working copy of the files, and every commit goes straight to the server. Without a network you can neither commit nor read the history.

Git is distributed. A clone is not just the files. It is the whole repository, with every commit and the whole history. You commit locally, even offline, and share with push and pull. The server is just one more copy, and two clones can even fetch directly from each other.

Imagine that the server disappears without a backup. With Dropbox, everyone still has the newest version of the files, but the older versions lived with the service. With SVN, only the working copies survive, and the history is gone. With Git, every clone has the whole history, so the team pushes it to a new server and carries on. Try it yourself with the buttons below the figure.

Git is the program on your machine. It works without a network and without an account. GitHub is a service that stores Git repositories and adds collaboration on top: pull requests, issues and automated tests. GitLab, Bitbucket and Codeberg do the same, and you can also run GitLab on your own server. To Git, each of them is just a remote: another repository at an address. Pull requests and issues live with the service, not in Git.

Watch: The server disappears

This is your clone of a small team project. The graph shows main in your repository, in Ada's and in origin, the shared server. The log shows all three commits, not just the newest files.

$ git log --oneline

Now we pretend the server disappears. We delete the shared repository, as a service shutting down or a failed disk would. Watch main in origin vanish from the graph.

$ rm -rf /course/origin.git

Fetching from the server no longer works. Git cannot find a repository at the address. Your origin/main is still there: it is your own note of where the server was last.

$ git fetch

What about Ada? She cloned the same repository. We look in her clone.

$ git log --oneline

You can keep working too. A commit is stored in your own repository and needs no server. Now you have four commits.

$ printf 'Offline notes\n' >> plan.md && git commit -qam 'Work offline'

The team creates a new, empty repository on a new server. Here it is a folder, but it could be GitLab, Codeberg or a new account on GitHub.

$ git init -q --bare /course/backup.git

origin is just a name for an address. We point the name at the new server. Nothing is sent yet.

$ git remote set-url origin /course/backup.git

One push, and main is back on a server with its whole history: all four commits, including the three made before the server vanished. Other branches and tags go the same way, with git push --all and git push --tags.

$ git push -u origin main

Tasks

  1. Show the history in your clone, one line per commit.
  2. Point origin at the new repository /course/backup.git.
  3. Restore the whole history on the new server, and let main track it.

Practise: Transfer: fetch straight from a teammate

The server is gone again, and this time Ada has a commit she did not manage to push. Her clone in /course/ada is a complete repository, so it can be a remote for you.

Tasks

  1. Get Ada's new commit into your main without any server.

Check yourself: Check yourself

What is the difference between Git and GitHub?

  • Git is the program that creates and stores the history. GitHub is a service that stores copies of repositories and adds collaboration on top.
  • GitHub is the newer version of Git.
  • Git is the command line, and GitHub is the graphical program for Git.

Team A uses SVN, and the server loses its disk without a backup. Team B uses Git, and the repository on GitHub is deleted. What does each team have left?

  • Both have only the files in their working copies.
  • Team A has only its working copies. Team B has the whole history in every clone.
  • Both have the whole history, because every version control system copies it to each machine.

You and a fellow student edit rapport.docx in a shared Dropbox folder at the same time. What happens?

  • Dropbox combines the changes, like a merge in Git.
  • One of you gets a conflicted copy, and you have to combine the changes by hand.
  • Whoever saves last gets an error, and the change is discarded.

GitHub is down for a whole day. What can you still do in your clone?

  • Nothing, because Git requires a GitHub login.
  • Read the history, create branches and commit. Push and pull must wait, or go to another remote.
  • Read the files, but not commit until GitHub is back.

The team moves from GitHub to GitLab by pushing its clones there. What does not come along?

  • Commits on main
  • The tags
  • Issues and the discussions in the pull requests

Common misconceptions

  • “Git and GitHub are the same thing.” Git is a program that runs on your machine, offline and without an account. GitHub is one of several services that store Git repositories and add collaboration on top.
  • “The history lives on GitHub.” Every clone has the whole history. GitHub holds one more copy. What exists only with the service is issues, pull requests and the discussions there.
  • “Dropbox is version control too.” Dropbox synchronises files and can bring back older versions of one file for a while, but it stores no snapshots of the whole project with a message saying why, and simultaneous edits become conflicted copies instead of a merge.

Read more

Version control

Version control is a system that remembers what a set of files looked like over time, so you can go back, see who changed what and why, and combine work done in parallel. Systems differ in where the history is stored and what it consists of.

Property File sync (Dropbox, OneDrive, Google Drive) Centralised (Subversion/SVN, Perforce) Distributed (Git, Mercurial)
What is stored Newest version of each file, older versions per file for a while Commits of the whole project with message and author Commits of the whole project with message and author
Where the history lives With the service On the server In every clone
Offline You edit the files; syncing waits You edit the files, but cannot commit or read the log Everything except fetch, pull and push
Simultaneous changes Conflicted copy that you combine by hand The server makes you update and merge before committing Merge or rebase of whole branches
The server disappears The files survive, the versions may be gone Only the working copies survive Every clone has the whole history

File sync is excellent for documents one person owns at a time. It is not version control: a version of one file does not tell you what the rest of the project looked like at that moment, nor why it changed.

Why Git is distributed

Linus Torvalds created Git in 2005 to develop the Linux kernel, with thousands of developers and no central server everyone had to wait for. A git clone therefore copies the whole repository: every commit, branch and tag. You notice the consequences every day:

  • Fast: log, diff, blame, branch and commit read from your own disk.
  • Offline: you can commit on the train and push when you are back online.
  • Robust: every clone is a complete copy. If the server disappears, you push a clone to a new server.
  • Safe to experiment: a branch is free, and nothing is shared until you push.
  • Integrity: every commit has an ID computed from its content, so altered or corrupted history is detected.

Distributed does not mean there is no server. Most teams agree that one repository, for example on GitHub, is the shared one. That is an agreement, not a technical difference: Git treats all repositories as equals.

Git, GitHub and the others

Name What it is
Git Free software that runs on your machine. Makes commits, branches and merges.
GitHub Hosting service for Git repositories, owned by Microsoft. Pull requests, issues, GitHub Actions.
GitLab Hosting service with merge requests, issues and CI. Can also run on your own server.
Bitbucket Atlassian's hosting service, closely tied to Jira.
Codeberg, Gitea, Forgejo Free software and non-profit services for Git hosting.
Azure DevOps Microsoft's platform for companies, with Git repositories.

Everything inside the repository can move to another service: git clone fetches every branch and tag, and git push --all and git push --tags send them on. A plain git push sends only the branch you are on. What the service adds on top, such as pull requests, issues, comments, wiki and CI settings in the service's database, lives only with the service. The services have their own tools to move those.

Remote: another repository

To Git, GitHub is just a remote: another repository at an address, with a short name such as origin. The address can be https://github.com/…, an SSH address or a folder on the same disk, like /course/origin.git in this course. That is why you can fetch from a teammate's clone just as well as from GitHub. The lesson Remotes and clone goes into depth.

When Git is not the right tool

Git is built for text. It happily stores images and PDFs, but cannot merge them, and large binary files make the repository heavy for everyone who clones it. Use Git LFS for large files, and file sync for documents that need no history. Git is not a backup of your machine either: only what you commit and push exists elsewhere.

Installing Git

In this course real Git runs in your browser, so you need to install nothing. When you want to use Git in your own projects, follow the page Install Git.

Official documentation