Version Control Systems

Why version control exists

Imagine writing an essay by saving files as final.docx, final_really_final.docx, and final_really_final2.docx. That chaos is exactly what version control systems (VCS) prevent for code. A VCS records who changed what, when, and why.

In DevOps, this matters because teams deploy often: 5 times a day, 50 times a day, sometimes more. Without version history, one bad edit can stall a release or erase someone else’s work.

Git is the most common VCS. It lets you:

• track changes over time
• restore older versions
• collaborate without overwriting teammates
• experiment in separate branches

Think of Git as a combination of a time machine, a backup system, and a shared notebook for software projects.

The core Git idea: snapshots, not file names

Git does not think in terms of project_v7 and project_v8. It stores snapshots of your project. Each saved snapshot is a commit: a labeled checkpoint with a message like Fix login timeout bug.

A simple Git workflow looks like this:

• git init creates a Git repository
• git status shows changed files
• git add <file> stages changes for the next snapshot
• git commit -m "message" saves that snapshot

git init
git status
git add app.py
git commit -m "Add welcome message"

The staging area is like a packing table before shipping a box. You choose exactly what goes into the next commit, instead of saving every half-finished edit.

Repositories, remotes, and teamwork

A repository (repo) is the project folder plus its Git history. On your laptop, that is a local repository. On GitHub, GitLab, or Bitbucket, it becomes a remote repository your team can share.

Common collaboration commands:

• git clone <url>: copy a remote repo to your machine
• git pull: bring down the latest changes
• git push: send your commits to the remote

A safe habit in DevOps is: pull before you push. If Priya updates docker-compose.yml at 10:05 and you push an older copy at 10:07, Git helps detect that mismatch instead of silently erasing her work.

This history is crucial during incidents: if a deployment fails at 2:14 PM, the commit log helps identify exactly what changed right before the failure.

Branches: experiment without breaking the main line

A branch is an independent line of work. If main is the stable highway, a branch is a side road where you can test ideas safely. In DevOps, teams often keep main deployable and do new work in feature branches.

Typical branch flow:

• create a branch for a task
• commit your changes there
• merge it back after review

git branch feature-login
git checkout feature-login
git add .
git commit -m "Add login form"

Why this matters: suppose production is stable on commit A. You build a risky feature on another branch and discover a bug. main stays clean, so deployment can continue. That separation is the practical power of version control: move fast without losing control.