The universal language of software teams — a plain-English guide to tracking code, collaborating with others, and never losing your work again.
Why Git? Imagine writing a 10-page document and accidentally deleting half of it — with no undo button. Now imagine that happening to thousands of lines of code on a live product used by millions. Git is the tool that makes sure that never happens. It keeps a complete history of every change ever made to a codebase, by everyone, forever.
As a DevOps engineer, Git is not optional — it is the starting point of every deployment pipeline, automation script, and infrastructure change you will ever touch. The good news: the basics take just a few days to learn, and the concepts will feel obvious once they click.
Before typing a single command, get the mental model right. Git is a version control system — it takes snapshots of your code over time, like a photo album of your project at different moments. Each snapshot is called a commit. If you break something, you simply roll back to an earlier photo. Install Git on your machine, set your name and email (Git tags every commit with this), and you're ready.
A repository (or "repo") is just a folder that Git is watching. You initialise one with git init, and from that point Git tracks every file inside it. The workflow you'll repeat thousands of times in your career: make a change → stage it with git add → save a snapshot with git commit. That's the heartbeat of Git, and everything else builds on top of it.
A branch is like a parallel universe for your code. You spin one off to try a new feature or fix a bug — without touching the main, working version. If your experiment works, you merge it back in. If it doesn't, you delete the branch and nothing is harmed. This is how every real development team works. Learn to create branches, switch between them, and understand what main (or master) means.
Git lives on your laptop. GitHub is a website where you store that same Git history online — like Google Drive but for code. Create a free account, create a repository on GitHub, then push your local project up to it. Now your code is backed up, shareable, and ready to be part of a team. This is also where every CI/CD pipeline you'll ever build will start.
A Pull Request (PR) is a formal way of saying "I've made some changes on my branch — please review them and merge them into main." It's the backbone of team collaboration. You'll open PRs, review other people's PRs, leave comments, and approve or request changes. This workflow is used by every tech company in the world, from startups to Google. Practice it even on personal projects.
A merge conflict happens when two people edit the same line of the same file and Git doesn't know which version to keep. It sounds scary, but it's just Git asking you to make a decision. Git marks the conflicting lines clearly in the file — you choose which version to keep, save it, and commit. Every developer encounters conflicts; the ones who stay calm and know how to resolve them stand out immediately.
GitLab is GitHub's main alternative — heavily used in enterprises and DevOps environments because it has built-in CI/CD pipelines, container registries, and infrastructure tools all in one place. Learn how GitLab differs from GitHub and explore its pipeline features. Also get comfortable with a few power commands: git stash (temporarily shelve work), git tag (mark releases), and git revert (safely undo a commit without rewriting history).
Don't wait until a feature is finished to commit. Save small, meaningful snapshots often. A good rule: if you'd be upset losing the last hour of work, commit right now.
"Fixed stuff" tells no one anything. Write messages like "Fix login bug when password has special characters." Your future self — and your teammates — will thank you.
Never work directly on main. Make a branch even for tiny changes. It's a habit that prevents disasters and mirrors exactly how real teams operate.
Every project — even small practice ones — should live on GitHub. It builds your profile, backs up your work, and gets you comfortable with the remote workflow that all jobs require.
Git has a reputation for being confusing — but that's mostly because people try to learn all the commands before understanding the concepts. Flip that order: understand why branching exists, why commits are snapshots, why merging is needed. Once the concepts click, every command makes perfect sense.
Learn Git properly once, and you'll never have to learn it again.