DEV Community

Cover image for Git: The Tool That Saves Your Code and Your Career
Nerav Doshi
Nerav Doshi

Posted on • Originally published at pipelineandprompts.com

Git: The Tool That Saves Your Code and Your Career

#git #devops #beginners

Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI

The Day I Nearly Broke Production

Early in my Cloud career, I was making what I thought was a small change to a configuration file. I'd been working on it locally, testing it, feeling confident. Then I committed and pushed — straight to the main branch.

Within seconds, a CI/CD pipeline picked up the change and started deploying it to production. My phone buzzed with an alert. My colleague looked over and said, very calmly, "Did you just push to main?"

I had. And the automated pipeline was already rolling it out.

We caught it in time. Barely. But that day I learned two things: first, that Git branching matters. And second, that understanding Git isn't optional if you work anywhere near production systems.

This article is the guide I wish I'd had before that moment.

What is Git?

Git is a version control system. In plain English, it tracks every change ever made to your code — who made it, when, and why.

Think of it like Google Docs' version history, but for code. Every time you save a meaningful change, Git records a snapshot. You can go back to any previous version, see exactly what changed, and undo mistakes.

But Git does more than just track changes. It lets multiple people work on the same codebase at the same time without overwriting each other's work. In a world where software teams can have dozens or even hundreds of developers, this is essential.

Every DevOps pipeline, every cloud deployment, every infrastructure change — it all starts with Git.

The Core Concepts

Before we get into commands, let's understand the key ideas:

Repository (repo) — A project folder tracked by Git. It contains your code and the entire history of changes.

Commit — A saved snapshot of your changes. Think of it as a checkpoint. Each commit has a message describing what changed and why.

Branch — A parallel version of your code. The main branch is the official version. You create new branches to work on features or fixes without affecting main.

Merge — Combining changes from one branch into another. When your feature is ready, you merge it into main.

Pull Request (PR) — A request to merge your branch into main. In teams, someone reviews your changes before they go in. This is where mistakes get caught — the step I skipped on the day I nearly broke production.

Essential Git Commands

Here are the commands you'll use constantly:

Setting up 

git init                    # Start tracking a folder with Git
git clone <url>             # Download a repository from GitHub
Enter fullscreen mode Exit fullscreen mode

Daily workflow 

git status                  # See what's changed
git add .                   # Stage all changes for the next commit
git commit -m "message"     # Save a snapshot with a description
git push                    # Upload your commits to GitHub
git pull                    # Download the latest changes from GitHub
Enter fullscreen mode Exit fullscreen mode

Branching 

git branch feature-login    # Create a new branch
git checkout feature-login  # Switch to that branch
git checkout -b feature-login  # Create and switch in one command
git merge feature-login     # Merge a branch into your current branch
Enter fullscreen mode Exit fullscreen mode

Seeing history 

git log                     # View commit history
git log --oneline           # Compact view of commits
git diff                    # See what changed since the last commit
Enter fullscreen mode Exit fullscreen mode

The Two Biggest Beginner Mistakes

Mistake 1: Working directly on main

This is exactly what I did. The main branch should always contain working, production-ready code. Never make changes directly on main. Instead:

  1. Create a new branch
  2. Make your changes there
  3. Open a pull request
  4. Get it reviewed
  5. Then merge

This workflow exists for a reason — it's the safety net between your code and production.

Mistake 2: Writing useless commit messages

Bad commit messages:

"fixed stuff"
"update"
"asdfgh"
Enter fullscreen mode Exit fullscreen mode

Good commit messages:

"Fix login timeout by increasing session duration to 30min"
"Add error handling for failed API responses"
"Update Kubernetes deployment to use image v2.3.1"
Enter fullscreen mode Exit fullscreen mode

Your future self — and your teammates — will thank you when they're trying to understand why a change was made six months from now.

How Git Connects to CI/CD Pipelines

This is where Git goes from "useful tool" to "essential infrastructure."

In a modern DevOps workflow, Git isn't just where you store code — it's the trigger for everything that happens next:

  1. You push code to a Git repository
  2. A CI/CD pipeline automatically detects the change
  3. The pipeline builds your application
  4. It runs automated tests
  5. If everything passes, it deploys to production

That's why my push to main was so dangerous. The pipeline was watching main for changes and automatically deploying whatever landed there. No human review. No safety check. Just straight to production.

Here's a simplified GitHub Actions example:

name: Deploy on Push
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm install
      - run: npm test
      - run: npm run deploy
Enter fullscreen mode Exit fullscreen mode

Every push to main triggers this pipeline. That's powerful — and exactly why you need branch protection and pull requests.

Git for Infrastructure (Infrastructure as Code)

Here's something that surprises many beginners: Git isn't just for application code.

In modern Cloud and DevOps, your infrastructure is defined as code too. Server configurations, network settings, Kubernetes deployments — all written as code files and stored in Git.

This means:

  • Every infrastructure change is tracked and auditable
  • You can review changes before they're applied
  • You can roll back if something breaks
  • Multiple team members can collaborate on infrastructure safely

Tools like Terraform, Ansible, and Kubernetes manifests all live in Git repositories. The same branching and pull request workflow applies.

Quick Recap

Here's everything we covered:

  • Git tracks every change to your code — who made it, when, and why
  • Branches let you work on changes without affecting the main codebase
  • Pull requests are the safety net between your code and production
  • The essential commands: git clone, git add, git commit, git push, git pull, git branch, git merge
  • Git triggers CI/CD pipelines — a push to main can automatically deploy to production
  • Infrastructure as code lives in Git too, making all infrastructure changes trackable and reversible

What's Next?

← Previous: Linux: The OS That Runs the Internet

Next up: What Are Containers? — We'll look at how Docker packages applications so they run the same way everywhere, and I'll share the moment when a shipping container analogy finally made it all click.

Found this useful? Share it with someone just starting their DevOps journey and follow along for a new article every week.

Top comments (0)