SRJahirTech

DevOps Roadmap — Part 5: Git & Version Control for DevOps

By Suraj Ahir October 31, 2025 6 min read

Git is not just a tool for software developers. DevOps engineers use Git constantly — for infrastructure code (Terraform, Ansible), CI/CD pipeline configurations, Kubernetes manifests, scripts, and documentation. If you are managing infrastructure as code, Git is how you track changes, collaborate with teammates, and roll back when something breaks. This part goes beyond basics to cover Git usage at a professional DevOps level.

Git Fundamentals — The Mental Model

Git tracks changes as snapshots, not differences. Each commit is a snapshot of your entire project at a point in time, along with a pointer to the previous snapshot. This is why Git is so reliable — you can always go back to any previous state. The three areas you work with constantly are the working directory (where you edit files), the staging area (where you prepare what goes into the next commit), and the repository (the full history of snapshots).

# Initialize a repo
git init

# Configure identity
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# Check what has changed
git status
git diff                  # unstaged changes
git diff --staged         # staged changes

# Stage and commit
git add filename
git add .                 # stage everything
git commit -m "descriptive message"

# View history
git log --oneline
git log --graph --oneline --all  # visual branch graph

Branching — The Core of Team Workflows

Branches allow parallel development without interfering with each other. In a DevOps context, branches represent different environments or features being worked on simultaneously.

# Create and switch to new branch
git checkout -b feature/add-monitoring
# Modern syntax:
git switch -c feature/add-monitoring

# List all branches
git branch -a

# Switch to existing branch
git checkout main
git switch main

# Merge branch into main
git checkout main
git merge feature/add-monitoring

# Delete branch after merging
git branch -d feature/add-monitoring

Git Workflows for DevOps Teams

GitFlow — Uses main, develop, feature, release, and hotfix branches. Structured but heavy. Good for scheduled releases.

GitHub Flow — Simpler: main branch is always deployable, all work happens in feature branches, merged via pull requests. Better for continuous deployment.

Trunk-Based Development — Everyone commits to main frequently, using feature flags to hide incomplete work. Used by high-performing DevOps teams for maximum CI/CD velocity.

Remote Repositories

# Clone a repository
git clone https://github.com/user/repo.git

# Add remote
git remote add origin https://github.com/user/repo.git

# Push to remote
git push origin main
git push -u origin feature/new-feature  # set upstream

# Pull latest changes
git pull origin main

# Fetch without merging
git fetch origin

# See remote info
git remote -v

Resolving Merge Conflicts

Merge conflicts happen when two branches modify the same part of a file. Git cannot automatically decide which change wins — you must resolve it manually. This is a skill every DevOps engineer needs because Infrastructure as Code files are frequently modified by multiple team members.

# When merge fails with conflicts
git merge feature/branch

# Git marks conflicted files
git status

# Open conflicted file - you'll see markers like:
# <<<<<<< HEAD
# your version
# =======
# their version
# >>>>>>> feature/branch

# Edit the file to keep what you want
# Remove the conflict markers
nano conflicted-file.yml

# Stage the resolved file
git add conflicted-file.yml

# Complete the merge
git commit

Git Rebase — Clean History

# Rebase feature branch onto main
git checkout feature/my-feature
git rebase main

# Interactive rebase (clean up commits)
git rebase -i HEAD~3   # edit last 3 commits

# Squash commits (combine multiple into one)
# In interactive rebase, change 'pick' to 'squash'

Undoing Mistakes

# Undo last commit (keep changes staged)
git reset --soft HEAD~1

# Undo last commit (keep changes unstaged)
git reset HEAD~1

# Undo last commit (discard changes - DANGEROUS)
git reset --hard HEAD~1

# Revert a commit (creates new undo commit, safe for shared branches)
git revert abc1234

# Stash work in progress
git stash
git stash pop

In Part 6, we will learn CI/CD fundamentals — what continuous integration and continuous deployment mean in practice, and how to set up basic pipelines that automate testing and deployment.

The Continuous Improvement Mindset

DevOps is not a destination but a continuous journey of improvement. The practices covered here — automation, monitoring, infrastructure as code, CI/CD pipelines — are tools in service of a deeper goal: enabling teams to deliver software changes to production quickly, safely, and reliably. The measurement that matters is not which tools you use but how long it takes to go from a committed code change to running in production, and how confident you are in that process. The best DevOps teams measure their deployment frequency, lead time for changes, change failure rate, and mean time to recovery (the DORA metrics), and treat these as engineering objectives to improve over time.

Putting It All Together

Every topic in technology and finance rewards the learner who goes beyond surface understanding to build genuine fluency. Fluency comes from repeated exposure, application in varied contexts, and reflection on what worked and what did not. The concepts discussed here are starting points — each one opens into a deeper field of study that could occupy years of focused learning. The most effective approach is not to try to master everything at once, but to pick the areas most relevant to your current goals, go deep there, and then expand. Depth in a few areas is more valuable than shallow familiarity with many. Build on what you know, stay curious about what you do not, and keep the practice of learning as a consistent daily habit rather than an occasional burst of effort.

The questions that make learning stick: How does this connect to what I already know? Where would I actually use this? What would happen if I tried to explain this to someone who knows nothing about it? What are the edge cases and exceptions? What is still unclear? Asking these questions transforms passive reading into active learning, and active learning is what builds the kind of understanding that is still accessible years later when you need it under real conditions.