Interactive Explainer

🎯Key Takeaways

Git is the source of truth for everything in DevOps: code, infrastructure, pipelines, configuration, documentation.

A commit is a snapshot (tree) with parent pointers and metadata. Branches are named pointers. Nothing is lost until garbage collection runs.

`git revert` for shared history (creates new undo commit). `git reset --hard` for local-only history (destructive).

`git reflog` is the ultimate undo — records every HEAD movement for 90 days, recovers "lost" commits.

`git rebase` creates linear history but rewrites SHAs — never rebase commits already on a shared branch.

Branch protection rules (no force-push, require PRs, require status checks) are non-negotiable for any team branch.

Git fundamentals for DevOps

Version control is the input to every CI/CD pipeline. Confident Git use — commits, branches, merges, rebases, and undoing mistakes — is a prerequisite for DevOps automation.

~8 min read

Be the first to complete!

What you'll learn

Git is the source of truth for everything in DevOps: code, infrastructure, pipelines, configuration, documentation.
A commit is a snapshot (tree) with parent pointers and metadata. Branches are named pointers. Nothing is lost until garbage collection runs.
`git revert` for shared history (creates new undo commit). `git reset --hard` for local-only history (destructive).
`git reflog` is the ultimate undo — records every HEAD movement for 90 days, recovers "lost" commits.
`git rebase` creates linear history but rewrites SHAs — never rebase commits already on a shared branch.
Branch protection rules (no force-push, require PRs, require status checks) are non-negotiable for any team branch.

Lesson outline

Why Git is the foundation of DevOps

Git is a distributed version control system that tracks every change to every file, with full history, branching, and collaboration. But for DevOps engineers, Git is more than a history tool — it is the source of truth for everything.

What lives in Git in a mature DevOps org

Application code — The obvious one. Every commit triggers a CI pipeline.
Infrastructure as Code — Terraform, CloudFormation, Pulumi configs. Every merge to main triggers a terraform apply via GitOps.
Configuration — Kubernetes manifests, Helm charts, Ansible playbooks. Environments are declared, not clicked.
CI/CD pipelines — GitHub Actions, GitLab CI, Jenkins files. The pipeline that deploys your code is itself version controlled.
Documentation — Runbooks, architecture decision records (ADRs), onboarding guides. Reviewed and versioned like code.
Policies and compliance — OPA policies, security scanning rules, access control configs. Auditable changes with author and timestamp.

Every DevOps practice — CI/CD, GitOps, IaC, feature flags — relies on Git as its event source. A git push is the trigger. A git commit is the audit trail. A git revert is the rollback.

The Git object model: what a commit really is

Understanding Git's internals helps you use it confidently and debug problems faster.

Git objects

Blob — The content of a file at a point in time. Identified by SHA-1 hash of the content. Two files with identical content share one blob.
Tree — A directory listing: maps filenames to blob or tree objects. Represents a directory at a point in time.
Commit — Points to a tree (root directory snapshot), has one or more parent commits, and contains: author, committer, timestamp, message. A commit SHA is a hash of all this — changing anything changes the SHA.
Ref (branch/tag) — A human-readable pointer to a commit SHA. main is just a file containing a 40-character SHA. Moving a branch just updates that file.
HEAD — A pointer to the current branch ref (or directly to a commit in "detached HEAD" state). HEAD~1 means "one commit before HEAD."

This model explains many 'magical' Git behaviors: `git diff` compares blob hashes, `git rebase` creates new commits (new SHAs — it is not moving commits, it is recreating them), and `git reset --hard` just moves the branch pointer.

Branches, merges, and rebases

Branches are cheap in Git — they are just pointers to commits. Creating a branch is O(1). The cost is in merging, where you need to reconcile diverged histories.

Merge vs rebase: when to use which

git merge — Creates a merge commit with two parents. Preserves the full history of when branches diverged and converged. Best for merging feature branches into main via PR — the merge commit marks "this feature landed here."
git rebase — Replays your commits on top of the target branch. Creates a linear history. Best for keeping your feature branch up-to-date with main before a PR. Rule: never rebase commits that have already been pushed to a shared branch.
git rebase -i (interactive) — Squash, reorder, edit, or drop commits before merging. Use to clean up a messy WIP commit history into a clean, reviewable set of commits.
Squash merge — GitHub/GitLab option: squash all PR commits into one merge commit. Keeps main history clean but loses individual commit context. Popular for trunk-based development.

The golden rule of rebase

Never rebase commits that have already been pushed to a shared remote branch that others have pulled. Rebase creates new commit SHAs — your colleagues now have the old SHAs in their local history. Their next pull will result in duplicate commits and a very confusing merge. Rebase is for local cleanup before push, or for rebasing a personal feature branch onto main.

Undoing mistakes safely

Git gives you multiple tools to undo mistakes, each with different safety properties for shared vs local history:

The undo toolkit

git revert <sha> — Creates a NEW commit that undoes the changes from a previous commit. Safe for shared history — does not rewrite anything. Use this to undo a bad commit that has already been pushed to main.
git reset --soft HEAD~1 — Moves the branch pointer back one commit but keeps changes staged. Use to un-commit but keep changes to recommit differently. Safe if not yet pushed.
git reset --hard HEAD~1 — Moves the branch pointer back and discards changes entirely. Destructive — changes are gone. Never use on pushed commits in a shared branch.
git reflog — Git's safety net. Records every movement of HEAD, even after reset --hard or rebase. If you accidentally lose commits, git reflog shows where HEAD was and you can git checkout <sha> to recover.
git stash — Temporarily shelves uncommitted changes. Switch branches, pull, do something else, then git stash pop to restore. Use git stash list to see all stashes.
git cherry-pick <sha> — Applies one specific commit from any branch onto your current branch. Use for hotfixes: cherry-pick a fix from a feature branch to main without merging the whole branch.

git reflog: the ultimate undo

Think you lost work with git reset --hard? Run git reflog. It shows every position HEAD has been at in the last 90 days. Find the commit SHA from before your reset, then git checkout <sha> or git reset --hard <sha> to restore it. This has saved countless engineers from 'I deleted everything' panic.

Git in CI/CD: how pipelines use Git events

Every CI/CD system is fundamentally a Git event listener. Understanding the events helps you design robust pipeline workflows:

Git events and their pipeline triggers

push to feature branch — Triggers: lint, unit tests, type check. Fast feedback to the developer. Does NOT deploy.
pull request / merge request opened — Triggers: full test suite, security scan, terraform plan (posted as PR comment), code review requirement. Deploy to ephemeral preview environment.
merge to main — Triggers: build, publish image, deploy to staging. The main branch is always deployable.
tag push (e.g. v1.2.3) — Triggers: production deployment. Semantic versioning tags are the gate for production releases.
scheduled (cron) — Triggers: dependency security scan, drift detection (terraform plan), performance regression tests.

Practical Git for DevOps: daily commands

How this might come up in interviews

Git interviews for DevOps roles test practical depth, not just `git commit` and `git push`. Be ready to explain: the difference between merge and rebase (and when to use each), how to undo a bad commit that is already in production (git revert), how to recover from `git reset --hard` (git reflog), and what `git bisect` does. Know the golden rule of rebase cold. Have a story about a git incident you resolved or prevented. Advanced: explain what happens internally when you run `git rebase` (new commit objects with new SHAs are created, parent pointers updated).

Quick check · Git fundamentals for DevOps

1 / 4

You accidentally ran `git reset --hard HEAD~3` and lost 3 commits of work. How do you recover them?

Key takeaways

Git is the source of truth for everything in DevOps: code, infrastructure, pipelines, configuration, documentation.
A commit is a snapshot (tree) with parent pointers and metadata. Branches are named pointers. Nothing is lost until garbage collection runs.
`git revert` for shared history (creates new undo commit). `git reset --hard` for local-only history (destructive).
`git reflog` is the ultimate undo — records every HEAD movement for 90 days, recovers "lost" commits.
`git rebase` creates linear history but rewrites SHAs — never rebase commits already on a shared branch.
Branch protection rules (no force-push, require PRs, require status checks) are non-negotiable for any team branch.

🧠Mental Model

💡 Analogy

Git is like a time machine for your codebase, with parallel universes (branches). Every commit is a photograph of your entire project at that moment. Branches are alternate timelines where you can make changes without affecting the main timeline. Merging is combining two timelines. Rebasing is taking everything you did in an alternate timeline and replaying it as if it happened in the main timeline. The reflog is your emergency undo button — it records every place the time machine has been, even if you tried to erase the evidence.

⚡ Core Idea

Git tracks content through hashes. A commit is a pointer to a tree (directory snapshot) with parent pointers and metadata. Branches are just named pointers to commits. Every 'history rewriting' operation (rebase, reset, commit --amend) creates new objects with new hashes — the old objects still exist in the reflog. Nothing is truly lost until garbage collection runs (90 days by default).

🎯 Why It Matters

Git is the event bus of DevOps. Every automation — CI pipelines, GitOps deployments, IaC applies, security scans — is triggered by a Git event. Engineers who understand Git deeply can debug broken pipelines faster, design better branch strategies, and confidently undo mistakes. The difference between a junior engineer who panics after an accidental `git reset --hard` and a senior who calmly runs `git reflog` and recovers in 30 seconds is Git internals knowledge.

Related concepts

Explore topics that connect to this one.

Suggested next

Often learned after this topic.

What is CI/CD?

Ready to see how this works in the cloud?

Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.

View role-based paths

Continue learning