CloudOpsGuide
fundamentals

Git for DevOps: The Commands and Workflows That Matter

Beginner
10 minutes
October 2026
CloudOpsGuide Team

Git for DevOps: The Commands and Workflows That Matter

DevOps runs on Git: infrastructure code, pipeline definitions, Kubernetes manifests — all of it lives and dies by commits. This isn't a beginner tutorial; it's the subset of Git that matters when you're shipping infrastructure.

Table of Contents

Daily drivers

git status                    # always
git log --oneline --graph     # readable history
git diff --staged             # what am I about to commit?
git blame file.tf             # who changed this line and why
git show HEAD~2               # inspect an old commit

Branch strategy for ops work

For infrastructure and config repos, trunk-based beats elaborate GitFlow:

  • main is always deployable.
  • Short-lived feature branches (feat/add-redis), merged via PR after plan/review.
  • Tags mark releases: git tag v1.4.0 && git push --tags.

Why? Infrastructure drift between long-lived branches causes more outages than it prevents. Small, reviewed, fast-merged changes win.

The commands that save you

git revert HEAD               # safe undo: new commit reversing the change
git reset --soft HEAD~1       # uncommit but keep the changes staged
git stash                     # shelve work mid-incident
git stash pop
git checkout -- file.yaml     # discard local changes to one file
git reflog                    # the "oh no" command — find lost commits

reflog deserves emphasis: it records every HEAD movement. Amend, rebase, delete a branch — reflog finds the commit. You've never truly lost work until reflog expires (~90 days).

Rebase vs merge

  • Merge preserves history as it happened — honest, sometimes messy.
  • Rebase replays your commits on top of the target — clean, linear history for short-lived branches.
git fetch origin
git rebase origin/main        # replay my branch on latest main
git push --force-with-lease   # safe force-push (refuses if others pushed)

Golden rule: never rebase shared branches. Rebase your own feature branch before merging; merge into main.

Commit hygiene that pays off at 3 AM

  • One logical change per commit — easy to revert exactly what broke.
  • Imperative subject line, ~50 chars: "Add retry to payment webhook" not "fixing stuff".
  • Body explains why, not what — the diff shows what.

Protecting the crown jewels

  • Secrets never enter git. Scan with gitleaks in pre-commit. If one slips, rotating the secret is mandatory — git filter-repo removes it from history but clones may already have it.
  • .gitignore early: .env, *.pem, terraform.tfstate, node_modules/.
  • Signed commits (git config commit.gpgsign true) for high-trust repos — proves authorship.

In GitOps workflows, git history is your change-management and audit trail. Treat it accordingly and incident reviews get dramatically easier.

Related Articles

Last Updated: October 2026 Author: CloudOpsGuide Team Difficulty: Beginner Estimated Reading Time: 10 minutes