DevOps Roadmap — Part 3: Git & Version Control
Git is not optional in modern software development. Every CI/CD pipeline starts with a Git event — a push, a merge, a tag. If you do not understand Git deeply, you cannot build proper DevOps pipelines. This part teaches Git from a DevOps perspective, not just the basic commands.
Why Git Matters in DevOps
Git is the source of truth for everything: application code, infrastructure configurations (Terraform, Ansible), CI/CD pipeline definitions, Kubernetes manifests, Docker files. When a DevOps engineer says "version control everything," they mean: if it matters to your system, it should be in Git.
Git Core Concepts
git config --global user.name "Suraj Ahir"
git config --global user.email "suraj@srjahir.in"
git config --global core.editor vim
# Initialize a new repository
git init my-project
cd my-project
# Clone an existing repository
git clone https://github.com/Srj0210/srjahir.github.io.gitThe Git Workflow
git status # What changed?
git diff # See exact changes
git add file.py # Stage specific file
git add . # Stage all changes
git commit -m "Add user authentication feature"
git commit --amend # Fix last commit message
git push origin main # Push to remote
git pull origin main # Pull latest changesBranching Strategy
Professional teams never commit directly to main. They use branches:
git branch # List branches
git checkout -b feature/user-auth # Create and switch to new branch
git checkout main # Switch to main
git merge feature/user-auth # Merge branch into current
git rebase main # Rebase current branch on main
git branch -d feature/user-auth # Delete merged branch
git push origin --delete feature/user-auth # Delete remote branchGitFlow — The Production Branching Model
GitFlow is a branching strategy designed for teams releasing software on a regular schedule:
- main — Production-ready code only. Every commit here is deployable.
- develop — Integration branch. Features merge here first.
- feature/* — Individual feature branches. Created from develop.
- release/* — Preparation for a release. Bug fixes only.
- hotfix/* — Emergency fixes to production. Created from main.
Git Tags — Marking Releases
git tag v1.0.0 # Create lightweight tag
git tag -a v1.0.0 -m "Release 1.0" # Annotated tag
git push origin v1.0.0 # Push tag to remote
git push origin --tags # Push all tagsUndoing Mistakes
git checkout -- file.py # Discard unstaged changes
git reset HEAD file.py # Unstage a file
git reset --soft HEAD~1 # Undo last commit (keep changes staged)
git reset --hard HEAD~1 # Undo last commit (discard changes)
git revert abc123 # Create new commit that undoes abc123.gitignore — What Not to Track
.env
venv/
__pycache__/
*.pyc
node_modules/
dist/
build/
*.log
.terraform/
*.tfstate
*.tfvarsIn Part 4, we will learn Docker — the containerization technology that changed how software is deployed.
Git Branching Strategies for Teams
How a team manages branches determines how smoothly work integrates and how safely releases are made. GitFlow uses long-lived main and develop branches with feature branches, release branches, and hotfix branches. It provides clear structure but can create large, difficult merges. Trunk-based development has everyone committing to a single main branch (or very short-lived feature branches), using feature flags to hide incomplete work. It enables faster integration and is favored by high-performing engineering teams with strong automated testing. GitHub Flow is a simplified version: main is always deployable, work happens in feature branches, and pull requests trigger code review and CI before merging. Most modern teams use GitHub Flow or trunk-based development.
Pull Requests and Code Review
Pull requests (PRs) or merge requests (MRs) are how code changes are reviewed before merging. A good pull request is small enough to review thoroughly (under 400 lines of change where possible), includes a clear description of what changed and why, links to the relevant ticket or issue, and passes all automated checks before requesting review. Good code review comments are specific, actionable, and explain the reasoning behind requested changes. Reviewing others' code carefully is one of the most valuable learning activities available — you see patterns, approaches, and mistakes you would not encounter just writing your own code.
Practice Exercise
Create a Git repository for a small project. Practice the complete GitHub Flow: create a feature branch, make changes, write a meaningful commit message following conventional commits format (feat:, fix:, docs:, refactor:), push the branch, and create a pull request on GitHub. Add a .gitignore file appropriate for your project type. Practice resolving a merge conflict by creating two branches that modify the same line, merging one into main, then attempting to merge the other and resolving the conflict manually.
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.