CSE Roadmap

Common tier · about 5 hours · 11 parts

Part 1 of 11 · 4 min read

Overview

In this module you will

  • Explain what version control is, and the difference between Git and GitHub.
  • Use the everyday loop with confidence: edit, git status, git add, git commit, git log.
  • Make a branch, merge it, and send your work to a remote for review.
  • Read a diff, resolve a merge conflict, and undo mistakes without losing work.
  • Keep secrets out of a repository, and know what to do in the right order if one gets in.

Why this matters for agents

Agent projects change in small, risky ways: a reworded prompt, a new tool, a different model name. Any of these can change behaviour without a single test failing. A habit of small branches and careful review is your main protection. Git history also shows you when behaviour changed, which is the first question you ask when an agent starts misbehaving.

Why we need Git

Imagine you are writing a project report. You save it as report.docx. A week later you make big changes, so you save a copy as report_v2.docx. A friend edits it and sends back report_v2_final.docx. You paste her changes into your copy and save report_v2_final_REALLY_final.docx.

Three weeks later your teacher says: "The explanation in your first version was better. Can you bring it back?" Which file has it? What exactly changed between them? Who changed it, and why?

Folders full of copies break down in four ways:

  1. You cannot tell which copy is the latest. The file names are guesses.
  2. You cannot see what changed. Two copies look the same until you compare them line by line.
  3. Two people cannot work at once. Someone's edits get overwritten, or you merge them by hand.
  4. You cannot go back safely. Trying a risky idea means making yet another copy, so people don't try.

Software projects have the same problem at a much larger scale: thousands of files, dozens of people and changes every hour. Programmers solved it with a tool that does the bookkeeping for them.

Version control

A tool that records every change to a set of files: what changed, who changed it, when, and why. It lets you compare versions, go back to an old one, and let several people work on the same project without overwriting each other.

Git

The most widely used version control tool. It is free, runs on your own computer and was created by Linus Torvalds in 2005 to manage the Linux kernel. When a job advertisement says "version control", it almost always means Git.

GitHub

A website that stores copies of Git projects online and adds ways to work together: pull requests, reviews and issue lists. GitLab and Bitbucket do the same job. Git is the tool; GitHub is a place to host the work. Beginners mix these up, and it helps to keep them apart from the start.

What Git gives you

  • A history. Every saved change stays, with a message saying why you made it.
  • Safe undo. You can look at, or return to, any earlier state of the project.
  • Parallel versions. You can try an idea on a separate line of work, called a branch, and keep it only if it works.
  • Teamwork. Many people can change the same project, and Git helps combine the changes.

Check yourself

Before moving on, can you answer these in your own words?

  • Why is final_v2_REALLY_final a bad way to keep versions?
  • What is the difference between Git and GitHub?
  • Name two things a version control tool can do that a folder of copies cannot.
For the curious Going deeper: centralised and distributed version control

Older tools such as CVS and Subversion keep the full history on one central server. You check files out, edit them and send them back. If the server is down, or you are offline, you cannot see history or save a version.

Git is distributed: every copy of a project (called a clone) contains the whole history. That is why most Git commands work with no internet, why they are fast, and why a lost server is not a lost project: anyone's clone can restore it. Hosting sites such as GitHub are convenient meeting points, not special in a technical sense.