Module 1: Version Control Foundations

Why Version Control Exists

If you have ever had files named report_final.docx, report_final_v2.docx and report_final_REALLY_final.docx, you already understand the problem version control solves. Software projects change constantly, often with several people editing the same files. Without a system to track changes, teams overwrite each other's work, cannot tell what changed or why, and have no safe way back when something breaks. Version control solves all of this, and Git is by far the most widely used version control system today.

What version control gives you

• Complete history. Every saved change (a commit) records what changed, who changed it, when and why. You can look at any file as it was on any date.
• Safe experimentation. Branches let you try a new feature or fix in isolation. If it does not work out, you discard the branch; the main code is untouched.
• Collaboration without chaos. Several developers work on the same project at once, each on their own branch, and their changes are combined (merged) in a controlled way. Conflicting edits are detected rather than silently lost.
• Undo for the whole project. If a change breaks the application, you can identify exactly which commit caused it and reverse it.
• Accountability and review. Changes can be reviewed before they are accepted, and history shows the reasoning behind decisions.
• Backup and portability. Every copy of a Git repository contains the full history, and hosting services such as GitHub keep a copy off your machine.

How Git works, in brief

Git is a distributed version control system. Older centralised systems kept history on one server, and developers needed a connection to it for most operations. With Git, every developer has a complete copy of the repository, including all history, on their own computer. You can commit, view history, create branches and compare versions offline, and you synchronise with others when ready.

Git thinks of your project as a series of snapshots. Each commit stores the state of all tracked files at that moment (efficiently, by reusing unchanged content) and points to the commit before it. The history is therefore a chain, or when branches are involved, a graph, of snapshots. Each commit is identified by a unique hash, a long string of letters and numbers such as a3f9c2e..., usually shortened to the first seven characters.

Git and GitHub are different things. Git is the free, open-source tool that runs on your computer and manages history. GitHub is an online service that hosts Git repositories and adds collaboration features such as pull requests, issues, project boards and automation. Similar services include GitLab and Bitbucket. This course uses GitHub for the collaboration modules, but the Git skills apply everywhere.

A realistic scenario

Consider a small web agency in Nairobi with three developers building a website for a hotel. Without version control, they share files over email and a shared drive. On Friday, Wanjiru updates the booking form while Brian updates the same file to fix the menu. Brian saves last, and Wanjiru's work vanishes. On Monday, the site breaks, and nobody knows which of the twenty changed files caused it, or what the working version looked like.

With Git, Wanjiru and Brian each work on their own branch. When they merge, Git combines their changes automatically, or flags the exact lines where they conflict so they can decide together. When the site breaks, they look at the history, find the commit that introduced the problem, read its message explaining why it was made, and revert it in minutes. The client's live site is restored, and nothing is lost.

Version control is not only for code. Writers, data analysts and designers use Git for documents, scripts, configuration and data pipelines. Git works best with text files, where it can show line-by-line differences; it can store binary files such as images, but cannot show meaningful differences for them, and very large binary files are better handled with extensions such as Git LFS.

Common misconceptions to avoid

• "Version control is only for big teams." Solo developers benefit just as much from history, branches and backups.
• "Git and GitHub are the same." Git is the tool; GitHub is one hosting service.
• "A shared drive is good enough." It keeps files, not a meaningful history of changes with reasons.
• "Committing means my work is backed up." A commit lives on your computer until you push it to a remote.