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 plae 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

Git branches are a fundamental feature of the Git version control system that allow multiple lines of development to occur independently within the same repository. By creating branches, developers can work on new features, fix bugs, or experiment with ideas without affecting the main (often called main or master) codebase. Each branch acts as an isolated workspace that can later be merged back into the main branch or other branches when changes are ready. This workflow makes collaboration, parallel development, and code management much more organized and efficient.

# 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

Adding, committing, and pushing are key steps in saving and sharing your work with Git. First, you stage changes using git add, which prepares modified or new files to be committed. Next, you commit those staged changes with git commit -m “your message”, creating a snapshot of your work and recording it in your local Git history. Finally, you push your commits to a remote repository (like GitHub) using git push, making your changes available to others and backing up your work online.

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

Merging in Git is the process of integrating changes from one branch into another. This is often done to combine work completed in feature branches back into the main branch, ensuring that everyone’s updates are included in the central codebase.

A pull request is used primarily on platforms like GitHub or Azure Devops. It lets you notify teammates that you want to merge changes from your branch into another branch (often main). Pull requests allow others to review your code, discuss potential improvements, and make sure everything works as expected before the changes are officially merged. This encourages collaboration, code quality, and a well-managed development process.

# 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 in Git happen when two branches have changes to the same part of a file and Git cannot automatically decide which version to use. This usually occurs during merging or rebasing. When a conflict arises, Git marks the file as conflicted, and you must manually review the differences, choose which changes to keep, and then mark the conflict as resolved before completing the merge. Handling conflicts is a normal part of collaborative development and ensures that code is integrated correctly.

# 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, Git is more than code storage:

CI/CD triggers: Commits can trigger build/deploy pipelines.
Infrastructure as Code: Terraform, Ansible, Kubernetes manifests live in Git.
Change management: Git logs serve as a record for audits.
Rollback safety: You can revert to any commit in history.

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

Learn the core Git commands — they form the foundation for everything else.
Use branches to keep work organized and avoid breaking production.
Commit small, meaningful changes with clear messages regularly.
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.