Git Basics Every DevOps Engineer Should Know

“In DevOps, Git is as essential as your terminal — it’s how you track, share, and deploy everything you build.”

Whether you’re just getting started or you’ve been hacking scripts together for years, Git is the backbone of modern software and infrastructure work. For DevOps engineers, it’s not just about storing code — it’s about collaborating effectively, managing change, and enabling automation.

Today I plan to talk through essential Git commands and workflows every DevOps engineer should know, with examples you can run today.

1. Understanding Git Basics

Git is a distributed version control system — meaning every clone of a repository is a full copy, complete with history.

Core concepts:

• Repository (repo) — Your project folder tracked by Git.
• Commit — A snapshot of your work at a point in time.
• Branch — A parallel line of development.
• Merge — Combining changes from different branches.
• Remote — A hosted copy of your repo (e.g., GitHub, GitLab, Bitbucket).

2. Setting Up Git

First, make sure Git is installed:

git --version

If it’s missing:

• macOS: brew install git
• Ubuntu/Debian: sudo apt install git
• Windows: Download Git

Configure your identity:

The first three commands we need to run. You can skip this step, but it will give you errors later, so let’s just knock it out. First, we’ll run our version again to make sure Git is indeed now installed. Now we need to tell Git just a little bit about ourselves: name and email address. This will be recorded in the code commits we’ll discuss in more depth later.

git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

3. Creating and Cloning Repositories

What is a Repository (Repo)?

A repository — often called a repo — is the home for your project’s code, documentation, and history. It’s managed by Git, which tracks every change over time.

Why they matter:

• Central place to store your code
• Keep a full history of changes so you can roll back if needed (which we don’t need as our code is always perfect, right!)
• Enables collaboration by allowing multiple people to work on the same project
• Sync between your local machine or machines and remote hosts like GitHub, GitLab, Azure DevOps, or Bitbucket

Think of a repo as your project’s time machine and collaboration hub all in one.

Create a new repo locally:

I personally like to keep all my locally cloned Git repos in a root git directory, such as E:\Git\*repos* on my Windows box. You can clone it wherever works best for your logic. Try to be consistent, you don’t want to go looking all over for a lost local repo. Also, do not store it in another file sync tool like Google Drive or OneDrive; that will only cause long-term problems. Let’s make sure we keep it clean with a proper source control system like GitHub.

mkdir my-project && cd my-project
git init

Clone an existing repo:

git clone https://github.com/user/repo.git

4. Working with Branches

Branches let you work on something without messing up main. Need to add a Terraform module? Create a branch. Need to fix a broken playbook? Branch. When you’re done, merge it back. If it doesn’t work out, delete the branch — no harm done.

# Create and switch to a branch
git checkout -b feature/add-terraform-module

# List branches
git branch

# Switch between branches to work on various features
git checkout main

5. Adding, Committing, and Pushing

The Git workflow is three steps: stage the files you changed, commit them with a message explaining why, and push to share with your team. Think of it as saving your game — add selects what to save, commit creates the save point, and push uploads it.

Track and save changes:

# Stage a specific file
git add main.tf

# Stage everything
git add .

# Commit with a message
git commit -m "Add S3 bucket module"

Push to remote:

git push origin feature/add-terraform-module

6. Merging and Pull Requests

When your branch is ready, you merge it back into main. You can do this locally with git merge, but in a team setting, you’ll almost always open a Pull Request (PR) first. PRs let your teammates review the changes, catch mistakes, and approve before the code lands in main. This is especially important for infrastructure code — a bad Terraform merge can take down real resources.

# Switch to main
git checkout main

# Merge changes
git merge feature/add-terraform-module

If you’re using GitHub/GitLab/Azure DevOps, create a Pull Request to review before merging.

7. Handling Conflicts

Conflicts happen when two people change the same lines in the same file. Git can’t guess which version you want, so it drops markers in the file and asks you to sort it out. It sounds scary, but it’s usually straightforward — open the file, pick the right version, remove the conflict markers, and commit.

# Edit conflicting files, then mark as resolved
git add conflicted-file.txt
git commit

Tip: Tools like VS Code, Meld, or KDiff3 make this easier.

8. Git in DevOps Workflows

For DevOps engineers, Git is the foundation everything else sits on. Here’s how it shows up in daily work:

Your IaC lives in Git. Terraform configs, Ansible playbooks, Kubernetes manifests — all version-controlled. When someone asks “what changed in production?”, the answer is in git log.

CI/CD pipelines trigger from Git. Push to main and GitHub Actions runs terraform apply. Open a PR and the pipeline runs terraform plan and posts the output as a comment. Git events drive your entire deployment workflow.

.gitignore is critical for IaC. Terraform state files contain secrets. Provider lock files should be committed; .tfvars with credentials should not.

# .gitignore for Terraform projects
*.tfstate
*.tfstate.backup
.terraform/
*.tfvars       # if they contain secrets
!versions.tf

Git log is your audit trail. When compliance asks “who changed the firewall rule and when?”, you have the answer: git log --all -- modules/firewall/.

Rollback is a git revert away. Bad deploy? Revert the commit, push, and let CI/CD reconcile the infrastructure back to the previous state.

9. Advanced Topics to Explore

Once you’ve mastered the basics, here’s where to go next:

• Git Rebase – Streamline commit history. → Atlassian Git Rebase Guide
• Git Hooks – Automate scripts on commit or push. → Git Hooks Documentation
• Git Flow – A branching model for managing releases. → Git Flow Overview
• Signed Commits (GPG) – Enhance commit authenticity. → Git Signed Commits

Key Takeaways

1. Learn the core Git commands — they form the foundation for everything else.
2. Use branches to keep work organized and avoid breaking production.
3. Commit small, meaningful changes with clear messages regularly.
4. Remember: Git is your DevOps safety net — use it to track not just code, but infrastructure and configuration.

In my next Git-related post, I’ll walk through Git branching strategies for DevOps teams, including Git Flow, trunk-based development, and feature branching best practices.