Why version control exists; Git vs GitLab vs GitHub
Beginner Core Git
Why this matters
You have already lived without version control: report_final.docx, report_final_v2.docx, report_final_v2_REAL.docx, and a colleague who overwrote your changes from a shared drive. Version control is the fix for that, made rigorous. Understanding why it exists makes every Git command feel reasonable instead of arbitrary.
The five questions
A team working on the same files needs answers to five questions, every day:
- What changed? Not "the file is different" but which lines.
- Who changed it, and when?
- Why? A note attached to the change.
- Can I go back? To yesterday's version, or last year's, without keeping copies by hand.
- Can two people work at once and combine their work without overwriting each other?
What Git is
Git is a version-control program. It runs on your computer, it is free, and it works without an internet connection. You point it at a folder, and from then on it can take snapshots of that folder whenever you ask, remember them forever, show you the differences, and combine snapshots made by different people.
Three properties explain most of Git's behaviour:
- Snapshots, not differences. Each commit records the complete state of every tracked file. Differences are computed when you ask for them.
- History is a chain. Every commit knows its parent. Following the chain backwards from the newest commit gives the whole history (lesson 2.4).
- Distributed. Every copy of a repository, on every computer, contains the full history. There is no single "master copy" that Git itself needs; the team chooses one copy (on GitLab or GitHub) as the meeting point.
Git, GitLab, GitHub
The three words are confused constantly, including by people who should know better.
| Git | GitLab | GitHub | |
|---|---|---|---|
| Is a… | program on your computer | website (or a company-hosted server) | website |
| Made by | an open-source community, started by Linus Torvalds in 2005 | GitLab Inc. | GitHub, owned by Microsoft |
| Does | records history, branches, merges | hosts repositories and adds issues, merge requests, reviews, pipelines, roles, wikis | the same, with pull requests, Actions, and a huge open-source community |
| Works without the others? | yes, completely | needs Git on your computer to push and pull | same |
| Costs | free | free tier, paid tiers | free tier, paid tiers |
So: Git is the tool; GitLab and GitHub are services built around it. Everything in Sections 2 to 7 of this course is Git and works identically whatever service you use. Sections 9 and 10 are about the services.
Before Git, most teams used centralized systems (Subversion, TFS), where one server held the history and every commit went straight to it. Git's distributed model is why you can commit ten times on a train and push once at the office, and why "commit" and "push" are two different words.
Do and don't
Do
- Say "Git" for the tool and "GitLab" or "GitHub" for the website.
- Commit locally as often as you like; it is free and private until you push.
- Expect to have the whole history on your machine; use it.
Don't
- Don't call GitHub "Git" in a bug report; people will misunderstand which part failed.
- Don't keep copies of folders "just in case"; that is what commits are for.
- Don't think of the GitLab copy as the only real one; it is the shared one.
Common mistakes
- Believing a commit is "saved to GitLab". It is saved to your computer.
git statussaysahead of 'origin/main'until you push. - Confusing the GitLab project with the Git repository. The project contains issues, settings and a repository; the repository is the part Git knows about.
- Assuming Git needs the internet. Everything except
push,fetch,pullandcloneworks offline.
Try it yourself
Goal: read the history of your playground and confirm the five questions have answers.
- In a terminal inside
trailguide, rungit log. - Identify the author, the date and the message of the first commit.
- Run
git log --onelineand compare.
Expected result: one commit (or more, if you did the earlier exercises) with your name, today's date and the message you typed.
Show solution
$ git log --oneline216f956 Initial import of trailguideAuthor: You <you@example.com> and the date. Those three facts, plus the message, are the "who, when, why" of every commit. "What" is one more command away: git show 216f956 lists every file in the snapshot.