Session 11: Git: Your code's history book

Imagine: you work on your game for three hours. You add a cool new weapon. But… now the rest of your game doesn’t work anymore. And you no longer know what exactly you changed. Three hours of work gone.

Git is the solution. Git remembers every version of your files. Like an endless “undo” button that never forgets what you did.

In this session you install Git, you make your first repository and you record what you do for good: step by step, version by version. And the fun part: Git doesn’t only work for code. Also for notes, school reports and stories.

What is Git?

Git is a version control system. It keeps track of what you change in your files, when you did it, and why. Every time you finish a piece of work, you make a commit: a snapshot of all your files at that moment.

What makes Git special:

• Every version is kept. You can always go back to a previous commit if something breaks.
• You work locally. Git runs on your computer. No internet needed.
• Git is fast. Even projects with thousands of files are checked in milliseconds.

Git was made by Linus Torvalds, the same person who built Linux. He needed something to work on the Linux kernel with thousands of programmers at the same time. In 2005 he built Git in a weekend. Today almost every developer in the world uses it.

Git is not only for code

Git was built for source code, but it works with every text file. A text file is any file you can open and read with Notepad or a simple editor: .py, .html, .css, .json, .txt, .csv, .md (Markdown), .yml, .toml, you name it.

What Git is not good at: binary files. Those are files that don’t consist of readable text: images (.png, .jpg), videos (.mp4), compiled programs (.exe), Word documents (.docx). Git can track them, but it is slower and you can’t see what exactly changed. With text files git diff shows every letter you added or removed. With a .png Git only says “this file has changed”, but not what changed about the image.

Markdown and notes

Many note-taking apps these days use Markdown (.md files) to store your documents. Think of:

• Obsidian: your notes are just .md files in a folder on your computer
• Notion: exports to Markdown
• Joplin: stores everything as Markdown
• Typora, Zettlr, Logseq: all Markdown-based

Because Markdown files are ordinary text files, you can let Git loose on them. You keep the history of your notes, you can go back to a previous version of a document, and you can share your notes via GitHub, exactly like you do with code.

Putting a folder of Markdown notes under Git is just as simple as a Python project:

mkdir mijn-notities
cd mijn-notities
git init
echo "# My Notes" > start.md
git add start.md
git commit -m "First note: start page"

From that moment on Git keeps every change to your notes. Writing a report for school in Markdown? Commit every paragraph. Working on worldbuilding for a story? Git remembers every version of your plot.

When to use Git for notes and when not

In short: anything that is text you can put in Git. Anything that is binary, better not.

Why version control?

Without Git your workflow looks like this:

game.py
game_backup.py
game_backup2.py
game_final.py
game_final_echt.py
game_final_echt_nieuwe_wapens.py

Recognise that? With Git you only need one file: game.py. Git remembers the rest.

What version control gives you:

• Never lose work again. Everything you commit keeps existing. Always.
• Understand what happened. You see exactly which lines you changed and when.
• Experiment without risk. Make a separate copy of your code (a branch), try something weird, and throw it away if it doesn’t work. Your original code stays intact.
• Work together. Several people can work on the same project at the same time without overwriting each other’s code.

What do you NOT put in Git?

Git is made for text files: files you write yourself: code, notes, configuration. There are things you’d better keep out of Git:

Why no passwords in Git? Because Git remembers everything, forever. Even if you delete a password later, it is still in the history. Anyone who ever sees your code can scroll back to that commit. And if your code ever ends up on GitHub, your password is on the internet. Forever.

Use a .gitignore file to tell Git which files it should ignore. You’ll find out about that in a moment.

Step 0: Git setup

Windows

1. Go to git-scm.com and download the Windows installer.
2. Double-click the downloaded file.
3. Click through the installation. The default options are fine.
4. Important: when picking the text editor, choose Nano or Notepad++ (not Vim, unless you already know Vim).
5. After the installation, open Git Bash (search for it in the start menu).

Mac

Open Terminal (search for “Terminal” in Spotlight) and type:

git --version

If Git is not installed, macOS asks you to install the developer tools. Click “Install”. Done.

Linux (Ubuntu/Debian)

sudo apt install git

Checking that it works

Open a terminal (Git Bash on Windows) and type:

git --version

You see something like git version 2.47.0. That means: Git is ready.

Step 1: Tell Git who you are

Git wants to know who you are, so it can put your name on every commit. You do this once, after that Git remembers it.

git config --global user.name "Your Name"
git config --global user.email "your@email.com"

Use the same email address you will use for GitHub later. That makes linking easier.

Tip: --global means: this setting applies to all your Git projects. You only have to do this once.

Step 2: Making your first repository

A repository (or “repo”) is a folder where Git keeps track of the versions. Let’s make one.

First make a new folder for your project:

mkdir mijn-eerste-git-project
cd mijn-eerste-git-project

Now you tell Git: “This folder is a repository.”

git init

You see: Initialized empty Git repository in .../mijn-eerste-git-project/.git/

Git has created a hidden .git folder. That is where it keeps everything: the history, the commits, the configuration. Never touch that folder by hand, because Git manages it itself.

Step 3: Committing your first file

Create a file. For example a Python file with one line:

echo 'print("Hello Git!")' > hallo.py

Now you tell Git: “Keep an eye on this file.”

git add hallo.py

With git add you put files in the staging area: a waiting room. You say to Git: “I want these changes in my next commit.”

Check what is ready:

git status

Git shows:

On branch master
Changes to be committed:
  new file:   hallo.py

Now comes the commit itself:

git commit -m "My first commit: added hallo.py"

What happens here? -m stands for “message”. The text between quotes is your commit message: a short explanation of what you changed. Git has now made a permanent snapshot of your project.

Good commit messages: Write in English (that is the convention in almost all projects). Start with a verb: “Add”, “Fix”, “Update”. Keep it short: 72 characters max.

Step 4: Tracking changes

Open hallo.py in a text editor. Change the line to:

print("Hello Git! You remember my code.")

Save the file. Now look at what Git sees:

git status

Git knows that hallo.py has changed. But what exactly has changed?

git diff

git diff shows exactly which lines you added (green with +) and removed (red with -). This is one of the most powerful things about Git: you literally see what changed, character by character, since your last commit.

Commit the change:

git add hallo.py
git commit -m "Update: greeting extended"

Step 5: Back in time

This is where Git gets magical. Suppose: you regret your last change. You want to go back to the first version.

First show all commits:

git log --oneline

You see something like:

a1b2c3d Update: greeting extended
e4f5g6h My first commit: added hallo.py

Every commit has a unique code, a hash. That long code (shortened to 7 characters) identifies exactly that one version of your project.

To see what hallo.py looked like in the first commit:

git show e4f5g6h:hallo.py

There is your original print("Hello Git!") again.

Do you really want to go back in time? That is possible:

git checkout e4f5g6h -- hallo.py

Now hallo.py is back the way it was in your first commit. Check with cat hallo.py. You see the old version. But don’t worry: your second commit is not gone. With git checkout master -- hallo.py you go back to the newest version.

Step 6: What does NOT go in Git: .gitignore

Create a file that Git should ignore:

echo "GEHEIM_WACHTWOORD=12345" > geheimen.txt

git status now shows this file as “untracked”. Git has seen it, but doesn’t know if you want to track it. You can ignore it with a .gitignore file:

echo "geheimen.txt" > .gitignore

Now run git status again and geheimen.txt has disappeared from the list. Git ignores it. (Do add .gitignore itself to Git with git add .gitignore and git commit, so others know what has to be ignored too.)

A good .gitignore for a Python project:

# Python
__pycache__/
*.pyc
*.pyo

# Secrets
*.env
secrets.txt

# Your editor
.vscode/
.idea/

Showcase

Show a coach and a buddy:

1. Your repository with at least 3 commits.
2. The result of git log --oneline: your commit history.
3. A git diff that shows what you changed.
4. Your .gitignore file.

See you next time!

“Next time: two versions of your code at the same time. You work on a new feature while the old version keeps working. That’s called branches, and it’s what makes Git really powerful.”

Take it home

1. Easy: Make a repository for your notes. Put a Markdown file with what you learned today in Git, and commit it.
2. Medium: Change something in your code or notes, use git diff to look at the change, and commit it with a good message.
3. Hard: Make three commits with different changes. Use git show to look at each version. Use git checkout to go back to the first commit, and then to the last one again.
4. Very hard: Make a Python project with a good .gitignore. Make sure __pycache__/ and .pyc files really are ignored (check with git status).

Stuck? Ask a coach at the next dojo, or just try something else. Programming is doing. Learning Git is doing.