Why you need Git

A story we've all lived through

Picture this: you're writing your thesis. You open Word, write a chapter, save thesis.docx. The next day you write more, get scared of breaking something, and make a copy thesis_v2.docx. A week later you send it to your advisor, who sends back notes in a file called thesis_advisor_notes.docx. You accept some of it, reject some of it, save it as thesis_FINAL.docx. A month later you mix up two versions, overwrite the new one with the old, and two weeks of work are gone.

With code the picture is the same, except instead of documents you get archives:

project_final.zip
project_final_v2.zip
project_final_v2_NEW.zip
project_final_v2_NEW_oleg.zip
project_final_v2_NEW_oleg_WORKING.zip

What's wrong with this:

• You can't see what changed between versions. To find out, you have to open both and eyeball the differences. diff will show you the difference, but not who made it or why.
• Two people can't work at the same time and cleanly merge their changes. If Oleg and you both edited the same file, someone's changes get overwritten.
• History gets lost when archives are renamed or deleted. Six months later you won't remember what was in v2_NEW.
• Rolling back to "how it was two days ago" only works by hand, shuffling files around.

There's one answer to all four problems: a version control system (VCS). It's a program that stores every version of your files and shows what changed, when, and by whom. Git is the most widely used VCS today.

What Git does instead of archives

In Word, Ctrl+S overwrites the file: the current version is saved, the previous one is gone. In Git, you decide when to record the state of the project. That recording is called a commit, and commits stack up into a history instead of overwriting each other. As long as you don't rewrite history yourself, old commits never go away.

A commit is a snapshot of the whole project at a point in time, plus metadata:

• the author (author): the name and email of whoever made the change;
• the time of the change;
• a message for humans, like "added chapter 2";
• a link to the parent commit. The very first commit has no parent.

Here's what a commit looks like from the inside (we'll cover the git cat-file command later, for now just look at the output itself):

tree 0d8a474fc67971fb3dd7616e26323d3066442555
author A <a@x> 1791585574 +0300
committer A <a@x> 1791585574 +0300

first

The tree line points to the snapshot of files. This is the first commit, so it has no parent line. The next commit will have one, pointing back to this one.

Every commit has an identifier: 40 hexadecimal characters like 0d02671e480600ea693f97d6ae51ebb130380aa4. It's called a hash. Git's output usually shows the first 7 characters, 0d02671, and that's enough to reference the commit.

Commits form a chain, a linear history:

a3f1c ← b8e2d ← c9f4e ← d1a7b   ← main
first   ch. 1   ch. 2   edits

The arrow points to the parent: every commit knows which one it came from. You can walk this chain: see what a file looked like a month ago, find who changed a specific line and when, go back to any point.

Thesis analogy: imagine Word kept every save with a "when" and "what changed" label, and at any moment you could say "bring it back to how it was three weeks ago".

What changes when you work with a partner

Say you're writing a course project with a partner. Oleg edits chapter 1, you edit chapter 3. Without Git, it looks like this:

[Monday]    Oleg → project_oleg.docx
[Monday]    you  → project_you.docx
[Tuesday]   ?    → how do you merge the two files back together?

With Git, each of you works on your own branch. A branch is a lightweight pointer that you stack your own commits under. When you're both ready, Git applies the changes on top of each other for you. If the edits are in different parts of the file, it merges them automatically. If you both edited the same line, Git stops and shows a conflict: deciding whose version is right is up to you.

This works because every participant has a full copy of the history, not just the current files. Old centralized VCSs (SVN, CVS) kept the history on a server, and you couldn't commit without a network connection. Git is distributed: you can commit and browse history offline, on a plane or in a basement with no wifi. You only need a network to exchange commits with others.

The server everyone exchanges commits with is usually called origin. Technically it's a repository just like yours. What makes it the main one is the team's agreement, not anything built into Git.

Core concepts in one place

Four terms you'll run into in every lesson from here on:

• Repository — the project together with its history. Locally this is the .git/ folder inside the project, where Git keeps commits, branches, and settings.
• Commit — a snapshot of the project's state plus metadata. One commit means one point in history.
• Branch — a named pointer to a specific commit. Inside .git/ it's a small file holding the commit's hash (41 bytes: 40 characters and a newline). That's why branches are cheap: people make a separate one for each task and delete it after merging.
• Remote — a remote repository you exchange commits with. Most projects have one, called origin.

The first branch appears together with the repository. With git init and no settings, it's called master, and Git 2.52 prints a hint that in Git 3.0 the default name will become main. GitHub and GitLab already name the first branch of new repositories main, so after git clone you'll usually see main. We'll cover how to set the name once for all your repositories in the next lesson.

Why this matters for a DevOps engineer

Git isn't just for programmers. Almost everything DevOps work touches lives in repositories:

• Infrastructure as Code: Terraform manifests, Ansible playbooks, Helm charts.
• Service configs: nginx, Prometheus, Alertmanager, Grafana dashboards.
• CI/CD pipelines: .gitlab-ci.yml, .github/workflows/*.yml.
• Documentation and runbooks for incidents.

Every change goes through review, the history is visible, and a bad change gets undone with git revert: it creates a new commit that's the opposite of the one that broke things. GitOps grew out of this practice. In it, the desired state of the system is described in a repository, and an agent in the cluster pulls it from there on its own and brings the system to match.

Common mistakes

• Thinking a commit only stores the changes. A commit describes the whole project. Git computes the diff between two commits only when you ask for it.
• Treating a branch as a copy of the project. A branch points to a commit and weighs 41 bytes. Creating one and later throwing it away is safe, and files never get duplicated.
• Treating origin as the main and only store of history. Everyone who cloned the repository has the full history. But if you haven't pushed your commits to the server, your teammates won't see them.
• Judging changes by the commit message. The message is written by a person and might not match what actually changed. The changes themselves are always visible in the history.
• Keeping only application code in Git. Configs, pipelines, and infrastructure change and break too, and they need history as well.

What you'll need for the tasks

• Git 2.20 or newer in a terminal (Linux, macOS, or WSL2). How to install it is in the lab's README.
• Understanding from this lesson: a commit stores the author, time, message, and a link to the parent; a branch is a file with a commit hash.
• The commands git log, git show, and git branch are given directly in the lab READMEs. We'll cover them in detail in later lessons.

In the next lesson we'll set up a repository from scratch and make the first commit by hand.