Teaching Git: What I Covered in Class

I used to teach college students programming, networking, and sysadmin topics. Git came up in several of those courses, not because every student would become a developer, but because version control shows up everywhere once you touch code, configs, lab scripts, or group projects.

This post is adapted from a slide deck I used in class. It is not a command cheat sheet. It is the framing I gave students before we opened a terminal: why Git exists, what makes it different, and how to think about it.

If you want hands-on steps, Git How To is still one of the best places to start.

Why use Git?

Version control is the only reasonable way to keep track of changes in code, manuscripts, presentations, and data analysis projects.

Before Git, I made numbered tar.gz files for projects. That works until you need to answer a simple question: what changed between version 7 and version 12? Exploring differences that way is painful. And if you forget to annotate what you changed, future-you has no context.

Git fixes that by recording small, annotated changes over time.

It also makes collaboration survivable. Have you ever had a partner send modifications spread across a dozen files? Or two people edit the same file at the same time? That gets ugly fast. git merge exists for exactly that problem.

What is Git?

Git is a distributed version control system.

That phrase matters:

• Version control: track changes to files over time, revert when needed, see who changed what.
• Distributed: every clone is a full copy of the project history, not just a checkout from a central server.

Each repository is independent and complete. Most everyday work happens locally: commit, branch, merge, browse history. Network access is for sharing, not for basic editing. Offline is the normal case, not an exception.

Each clone is also a backup. Lose the server? You still have the history on someone’s laptop.

A little history

Git appeared in 2005 after the Linux kernel developers lost free access to BitKeeper, a proprietary SCM they had been using. Linus Torvalds wanted something distributed like BitKeeper, but none of the free tools at the time met his performance and workflow requirements.¹

He set out to build the opposite of CVS: distributed, fast, and resistant to accidental or malicious history corruption. The first version was self-hosting within days. By late 2005, Junio Hamano had taken over maintenance, and Git has been the default choice for open-source development ever since.¹

You do not need this history to use Git day to day. But students often ask “why does everyone use this?”, and the answer is partly timing, partly design, and partly that the Linux kernel proved it at scale.

What’s in a name?

Torvalds has joked that he names projects after himself: Linux, then Git. In British slang, git means an unpleasant person. The Git manual calls it “the stupid content tracker.”

The project readme offers other expansions depending on your mood:

• A pronounceable three-letter name not used by common UNIX commands
• Global information tracker: when it works and angels sing
• G*** idiotic truckload of [expletive]: when it breaks

Students usually appreciate that even the creator admits the learning curve.

Design characteristics (the short version)

The deck had a full slide on Git’s design goals. In class, I boiled it down to five ideas:

Non-linear development. Branches in Git are cheap. A branch is basically a pointer to a commit. You are expected to branch, review, and merge often, not save merges for the end of the semester.

Distributed by default. Like Mercurial, Bazaar, and BitKeeper before it, Git gives every developer a full history locally. You copy changes between repos; merges work the same whether the branch was yours or a collaborator’s.

Cryptographic history. Each commit’s ID depends on the entire chain of history before it. Once something is published, rewriting old history without leaving evidence is hard by design.¹ That is intentional, especially when you are grading group work or auditing who changed a config.

Toolkit, not monolith. Git is a set of small programs you can chain together. Merge strategies are pluggable. Some housekeeping (git gc) runs automatically; you can also trigger it when you care about disk space.¹

Compatibility. Repos can be shared over HTTP, SSH, or Git’s own protocol.² There are bridges to Subversion and CVS for legacy environments, useful in enterprise and academic IT where old tooling dies slowly.

If you want the full diagram of how objects flow through the system, the Wikipedia Git article still has a clear picture.

Git clients

You can use Git many ways:

• git on the command line: still the reference implementation and the fastest way to learn what is actually happening
• Shell helpers: on Windows, posh-git adds useful context to your PowerShell prompt
• GUI clients: fine for visual diffs and staging, but some GUIs hide the concepts that make Git worth learning in the first place

When I taught sysadmin students, I pushed the command line first. When something breaks, the error messages make more sense if you have seen the underlying commands.

Some GUIs try to hide the mechanics that make Git worth understanding in the first place. That is a point I borrowed from my own slide notes, and one I still agree with.

Git is not GitHub

Git is the version control tool. GitHub is a hosting service, one place to store and collaborate on Git repositories. New students conflate them constantly.

GitHub is the name most people recognize. Microsoft acquired GitHub in 2018 for $7.5 billion. That was a watershed moment: Git had become infrastructure, not a niche kernel-developer utility. Microsoft had already been using Git internally for years before the acquisition.³

You are not locked to GitHub. Other hosted options include GitLab, Bitbucket, and Codeberg. You can also self-host: Gitea, Forgejo, a self-managed GitLab instance, or a bare repository on your own server over SSH. The Git commands are the same; only the remote URL changes.

I use a mix of hosted and self-hosted remotes depending on the project. Students should know the tool and the hosting are separate decisions.

Adoption (then and now)

When I built this deck, the 2015 Stack Overflow Developer Survey reported 69.3% of developers using Git, far ahead of Subversion (36.9%), TFS (12.2%), and Mercurial (7.9%).⁴

That number is higher now. Git won. Subversion still lingers in older orgs, and every student eventually runs into a professor or employer who says “we use SVN.” Knowing why Git replaced those systems helps you adapt instead of arguing.

Where to go next

For a guided walkthrough with real commands, I still point people at githowto.com. It is clear, practical, and free.

From there, the path depends on the student:

• Programming courses: branch per feature, commit often, write messages that explain why
• Networking / sysadmin labs: track router configs, Ansible playbooks, and lab rebuild scripts
• Group projects: agree on a branching workflow before the first merge conflict ruins a deadline

Git is not intuitive on day one. Neither was the shell. It pays off the first time you need to undo a mistake without panic, or merge two people’s work without emailing zip files.

That was always the goal of the lecture: not to make students experts in one hour, but to give them a mental model that survives the first broken clone.