Version Control Basics: Git for the Rest of Us

The previous post in this path covered what DevOps actually is — the culture and practices that connect development and operations. This post covers the foundational tool that makes modern software collaboration possible: Git, the version control system that tracks changes to your files and lets multiple people work on the same project without overwriting each other's work.

If you have ever saved a file as report_final.docx, then report_final_v2.docx, then report_ACTUALLY_final.docx, you understand the problem version control solves. Git replaces the chaos of manual versioning with a system that tracks every change, lets you go back to any previous version, and manages the complexity of multiple people editing the same files.

Git has a reputation for being confusing. That reputation is earned — the full Git manual covers hundreds of commands with thousands of options. But the daily reality is simpler. A handful of commands cover the vast majority of what you need, and the mental model behind those commands is straightforward once it clicks.

The Mental Model: Snapshots, Not Files

Git does not track files. It tracks snapshots of your entire project at specific points in time. Each snapshot — called a "commit" — is a picture of every file in your project at the moment you saved it. Git stores these snapshots efficiently, only recording the differences between consecutive snapshots.

Think of it like a timeline of your project. Each commit is a point on the timeline. You can move forward and backward along this timeline, seeing exactly what the project looked like at any point. You can compare any two points to see what changed between them.

This is why Git is powerful: it gives you a complete, navigable history of your project. Accidentally deleted a function? Go back to the commit before the deletion. Need to see what changed last week? Compare this week's commit to last week's. Curious who wrote a specific line of code and when? Git can tell you.

The Core Workflow

The daily Git workflow has three steps, and once you internalize them, version control stops feeling like an obstacle and starts feeling like a safety net.

Make changes. Edit your files as you normally would. Git is watching the folder but it is not recording anything yet. Your changes exist only on your machine, in your working directory.

Stage your changes. Tell Git which changes you want to include in your next snapshot. This is the "add" step — you are selecting the changes that belong together as a logical unit. Maybe you fixed a bug in two files — you stage both files because together they represent one complete fix.

Commit your changes. Take the snapshot. Git records all staged changes as a new commit, with a message you write describing what changed and why. "Fixed the login timeout bug by increasing the session duration" is a good commit message. "Fixed stuff" is not.

This three-step flow — change, stage, commit — is the rhythm of working with Git. You do it dozens of times a day, and each commit adds another point to your project's timeline.

Branches: Parallel Timelines

Branches are where Git gets genuinely useful for collaboration. A branch is a parallel timeline — a copy of your project where you can make changes without affecting the main timeline.

The main branch (often called main or master) is the canonical version of your project — the version that represents the current state of things. When you want to add a feature or fix a bug, you create a branch. Your branch starts as a copy of main, and you make your changes there. If the changes work, you merge the branch back into main. If they do not work, you delete the branch and main is untouched.

This is why branches matter for teams. Five developers can each work on their own branch simultaneously. Alice is building a new feature on her branch. Bob is fixing a bug on his branch. Neither affects the other's work, and neither affects main until they are ready. When Alice finishes, she merges her branch into main. When Bob finishes, he merges his. If their changes do not overlap, Git handles the merge automatically.

When their changes do overlap — both edited the same line of the same file — Git flags it as a "merge conflict" and asks a human to resolve it. This sounds scary. In practice, it is usually a minor inconvenience: you look at both changes, decide which one to keep (or combine them), and move on.

The Commands That Matter

You do not need to memorize a hundred Git commands. These cover the daily workflow.

git status — Shows what has changed since your last commit. What files were modified? What is staged? What is not? This is your "where am I?" command. Run it constantly.

git add — Stages changes for the next commit. git add filename stages a specific file. git add . stages everything that changed. Use the specific version when you want to be deliberate about what goes into each commit.

git commit — Takes the snapshot. git commit -m "Your message here" creates a commit with a descriptive message. Write messages that your future self will thank you for.

git pull — Downloads changes from the shared repository (the remote) and merges them into your local copy. Do this before you start working to make sure you have the latest changes from your team.

git push — Uploads your commits to the shared repository so your team can see them.

git branch — Lists your branches or creates a new one. git branch feature-name creates a new branch. git checkout feature-name switches to it.

Working with a Remote Repository

Git works locally — every command we have discussed so far happens on your machine. But collaboration requires a shared location where everyone's changes come together. This is the remote repository, typically hosted on GitHub, GitLab, or Azure DevOps.

The remote is the source of truth for the team. Your local repository is your personal workspace. The workflow: pull the latest changes from the remote, make your changes locally, commit them locally, and push them to the remote when they are ready for others to see.

Pull requests (or merge requests, depending on the platform) add a review step. Instead of pushing directly to main, you push your branch to the remote and open a pull request that says "here are my changes, please review them." A teammate reviews the changes, provides feedback, and approves the merge. This process catches bugs, shares knowledge, and maintains code quality.

Mistakes Are Recoverable

The most important thing to understand about Git is that almost every mistake is recoverable. Committed something you should not have? Revert the commit. Accidentally deleted a file? Restore it from the previous commit. Made a mess of your branch? Delete it and start fresh from main.

This safety net is the real value of version control. It gives you the confidence to experiment, refactor, and make bold changes because you know that if something goes wrong, you can always go back. The project's history is always there, always complete, and always recoverable.

The one rule: commit early and commit often. Every commit is a save point you can return to. An uncommitted change that gets lost is gone forever. A committed change that causes problems is a recoverable situation.

The Takeaway

Git tracks the history of your project as a series of snapshots. The daily workflow — change, stage, commit — is simple once the mental model clicks. Branches let multiple people work simultaneously without conflict. Remote repositories enable collaboration. And the complete history means that mistakes are recoverable, not catastrophic.

You do not need to master Git's hundreds of commands. Master the handful that cover the daily workflow, understand the mental model of snapshots and branches, and let Git do what it does best: keep your project safe while you focus on the actual work.

---

Next in the "DevOps Foundations" learning path: We'll cover CI/CD basics — what happens after you push your code, and how automation turns your commits into running software.