Git for Beginners: Version Control Fundamentals for DevOps

Every DevOps workflow, from a simple app deployment to a full GitOps pipeline, starts with the same building block: a Git repository. If you've only ever used Git by copying commands from Stack Overflow, this guide is meant to actually build the mental model underneath them.

The core idea: snapshots, not diffs

A common misconception is that Git stores a list of changes between file versions. It doesn't. Each commit is a full snapshot of your project at that moment (Git is smart about not literally duplicating unchanged files, but conceptually, think snapshots). This is why Git can jump to any past commit instantly, rather than replaying a long chain of diffs.

The three areas every change passes through

1. Working directory - the actual files you're editing right now
2. Staging area (the index) - changes you've marked as ready to be committed, via git add
3. Repository - the permanent, committed history, created via git commit

git init                     # start tracking a new project
git add server.js            # stage one file
git add .                    # stage everything changed
git commit -m "Add server"   # commit whatever is staged
git status                   # see what's staged, unstaged, or untracked

HEAD: where you are right now

HEAD is Git's pointer to whatever commit or branch you currently have checked out. Most of the time it points at the tip of a branch, and moves forward automatically each time you commit. Understanding HEAD makes commands like git reset and git log far less mysterious.

Branching: parallel lines of work

A branch is just a movable pointer to a commit. Creating one is cheap and instant, which is exactly why Git encourages branching for every feature or fix.

git branch feature-login          # create a branch
git switch feature-login          # move to it (or the older git checkout feature-login)
git switch -c feature-signup      # create and switch in one step
git merge feature-login           # bring those commits into your current branch

If your branch is simply ahead of the one you're merging into, with no diverging changes, Git can do a fast-forward merge: it just moves the branch pointer forward, no new commit needed. Once both branches have diverged, Git creates a real merge commit joining the two histories together.

Working with remotes

A remote is a reference to a copy of the repository hosted elsewhere, like GitHub. Your local repository and the remote are separate until you explicitly sync them.

git clone https://github.com/org/repo.git   # copy a remote repo locally
git fetch origin                             # download updates, don't apply them yet
git pull origin main                         # fetch AND merge into your current branch
git push origin feature-login                # upload your commits to the remote

git fetch and git pull are often confused: fetch is the safe, look-before-you-leap option, it downloads what's new without touching your working files. Pull does that and immediately merges it in.

Undoing things, carefully

Two commands look similar but behave very differently once you've already pushed and shared a commit:

• git revert <commit> creates a brand new commit that undoes an earlier one. History moves forward, nothing is erased.
• git reset actually moves your branch pointer backward, rewriting what it points to.

For anything already pushed and shared with teammates, revert is almost always the safer choice; rewriting shared history with reset (or a force-push) can silently drop other people's work.

Where to go next

Once branching and merging feel natural, the next layer is how teams actually use Git day to day, pull requests, code review, and CI pipelines that run automatically on every push. Try the Git quiz on OpsQuiz to test what you've just learned, then check out our CI/CD pipelines guide next.