Resources Git Git basics

Git basics · Lesson 1 of 6 · about 12 minutes

What Git solves

Before your first commit, it helps to know the problem Git fixes: keeping every version of your work, knowing what changed and why, and working with other people without overwriting each other.

By the end you'll know

  • The problems Git solves, and why "save as final_v2" stops working
  • What a commit is, the single most important idea in Git
  • The difference between Git and GitHub
  • Why there's no single "real" copy, and which copy counts anyway
  • How to set Git up on your laptop, ready for Lesson 2

The problem: final_v2_REALLY_final

Most people's first version control looks like this:

TEXT
report.docx
report_v2.docx
report_v2_fixed.docx
report_final.docx
report_final_REALLY_final.docx

It works for a while, then it doesn't. Which one is actually the latest? What changed between v2 and "fixed"? If "final" broke something, what did the version before it look like? Now imagine a project with hundreds of files, and three people editing them at once, emailing copies back and forth. Someone's changes always get lost.

Code has this problem worse than anyone, because one wrong character can break everything, and you need to know exactly what changed, when, and why.

What Git does

Git is a version control system: a tool that keeps track of every version of your project. Instead of copying files, you tell Git "save a snapshot of everything, right now". Each snapshot is called a commit, and it records:

  • What every file looked like at that moment
  • Who made it, and when
  • Why, in a short message you write, like "Fix the login button"

Git keeps every commit, so your project's whole history is there to look at, compare and go back to. And because it only stores what changed between commits, keeping all that history takes surprisingly little space.

Think of save points in a video game. Before a hard level, you save. If it goes badly, you load your save and try again, instead of starting the whole game over. A commit is a save point for your project, except you can keep thousands of them, each with a note saying what you'd just done, and you can jump back to any of them.

A folder that Git is tracking is called a repository, or repo. Everything you'll learn in this track happens in one.

Git and GitHub are different things

People mix these up all the time:

  • Git is the tool. It runs on your laptop, keeps your history, and works without the internet.
  • GitHub is a website that hosts Git repositories online, so you can share them and work on them with other people. It adds things Git doesn't have, like pull requests (Lesson 5) and automated checks. GitLab and Bitbucket are similar sites.

You can use Git without GitHub. You can't really use GitHub without Git.

Every copy is complete

Here's the part that surprises people. When you download a repository from GitHub, you don't get just the latest files: you get the entire history, every commit, on your laptop. Your copy is as complete as the one on GitHub. That's why Git is called distributed: there are many full copies, not one central one.

Every copy of a repository has the full historyYour laptop, GitHub and a coworker's laptop each hold the same full history of commits A, B and C. You and your coworker push your new commits to GitHub and pull each other's from it. GitHub is the copy everyone agrees to share, and the live site is built from GitHub's copy.Your laptopABCthe full historyworks offlineGitHubABCthe copy everyoneagrees to shareA coworker's laptopABCthe full historyworks offlinepushpullpushpullThe live site is built from hereEvery copy is complete. Which one counts is an agreement, not a technical rule.
Your laptop, GitHub and a coworker's laptop each hold the whole history. You share commits by pushing to GitHub and pulling from it, and deployments are built from GitHub's copy.

That raises a good question: if every copy is complete, which one is the "real" one? Technically, none of them. In practice, the team agrees that the copy on GitHub is the one that counts. That's where everyone shares their work, and it's what deployments are built from. Your laptop's copy is your workspace: you make commits there, then send them to GitHub with push, and get everyone else's with pull. Lesson 5 does both.

What Git is not good at

  • Big files that aren't text, like videos, design files or huge datasets. Git can store them, but every version is kept forever, so the repository balloons. There are add-ons for this, but most projects simply keep them elsewhere.
  • Secrets. A password committed to Git is in the history from then on, even if you delete it in the next commit, because the earlier commit still has it. Lesson 2 shows how to keep files out of Git before that happens.

In my real setup

This website is a Git repository. Every lesson you're reading went in as a commit with a message like "Publish Docker Lesson 4: Your first Dockerfile", and its whole history is on GitHub. Vercel, the service that hosts the site, watches the GitHub copy: when a change lands there, it builds the site and publishes it. My laptop never talks to Vercel directly.

My production cluster for CivicGrid takes the same idea further. Its entire setup lives in a Git repository, and a tool called Argo CD makes the cluster match what's in Git. So the answer to "what's running in production right now?" is "whatever the latest commit says", and the way to undo a bad change is to undo its commit. Git isn't just where my code lives; it's the record of every decision I've made about how things run.

The history also keeps me honest. A few lessons on this site first went out as hidden drafts by mistake, and the fixes are right there in the commit history, one after another. Nothing in Git is quietly papered over.

When you don't need Git

Not much, honestly. A shopping list doesn't need version control. But anything you'll change more than a few times, and care about getting back, benefits: code, configuration, notes, even writing. Once it's a habit, it costs a few seconds per commit.

Get ready for Lesson 2

Check whether Git is installed:

BASH
git --version

If you see a version number, like git version 2.43.0, you're set. If not:

  • macOS: running git --version usually offers to install Apple's developer tools, which include Git. Accept, and wait for it to finish. Or, with Homebrew, brew install git.
  • Windows: install Git for Windows, which also gives you Git Bash, a terminal that runs every command in this track.
  • Linux: install it with your package manager, for example sudo apt install git.

Then tell Git who you are. Every commit records a name and email, so set them once:

BASH
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main

Use your own name and email; if you'll use GitHub, use the email on your GitHub account. The last line makes new repositories start with a branch called main, which is what GitHub uses (Lesson 4 explains branches). Check what you set:

BASH
git config --global --list

Check yourself

  1. What does a commit record?

  2. What's the difference between Git and GitHub?

  3. You download a repository from GitHub. What's on your laptop?

  4. If every copy of a repository is complete, which one counts as the real one?

  5. You commit a password, then delete it in the next commit. Is it gone?

  6. Why set user.name and user.email before your first commit?

Key terms

  • Version control: keeping track of every version of a project, so you can compare and go back.
  • Git: the most popular version control tool. It runs on your laptop.
  • Repository (repo): a folder whose history Git is tracking.
  • Commit: a snapshot of the project, with the author, the time and a message.
  • GitHub: a website that hosts Git repositories and adds sharing features.
  • Distributed: every copy of a repository has the full history.
  • Push / pull: send your commits to another copy / get commits from it.

Go deeper

From www.kwamib.dev/resources/git/what-git-solves