Git Basics for DevOps: Clone, Commit, and Log Explained with Proven Examples 2025

Picture this: It’s your first day at a new company as a DevOps engineer. Your team lead hands you a GitHub repository URL and says, “Here’s our Terraform infrastructure code. Can you add a new S3 bucket configuration and deploy it to staging?”

If you’re breaking into a cold sweat right now, don’t worry. Understanding Git basics for DevOps is your first step toward confidently managing infrastructure code, collaborating with your team, and becoming the DevOps engineer you aspire to be.

In this comprehensive guide, we’ll walk through the essential Git commands every DevOps professional needs to know, using a real-world scenario that you’ll likely encounter in your day-to-day work.

Why Git is Essential for DevOps Engineers

Before diving into commands, let’s understand why Git isn’t just another tool in your DevOps toolkit—it’s the foundation everything else is built on.

DevOps is all about collaboration, automation, and maintaining reliable systems. Whether you’re managing Kubernetes manifests, Terraform configurations, Ansible playbooks, or CI/CD pipelines, you need a way to:

• Track changes to your infrastructure code over time
• Collaborate with team members without stepping on each other’s work
• Roll back problematic deployments quickly
• Maintain different versions of your configurations for different environments

Git solves all these challenges, making it indispensable for modern DevOps practices. In fact, the entire Infrastructure as Code (IaC) movement depends heavily on version control systems like Git.

Our Real-World Scenario: The Terraform Repository

Throughout this Git for DevOps beginners tutorial, we’ll follow Maya, a junior DevOps engineer who just joined CloudTech Solutions. Her first task is to add a new AWS S3 bucket to the company’s existing Terraform infrastructure.

Here’s what Maya needs to do:

1. Get a copy of the company’s Terraform repository
2. Add her S3 bucket configuration
3. Commit her changes with a clear message
4. Review what she’s done before pushing to the team

Let’s follow Maya’s journey and learn the essential Git commands along the way.

Step 1: Cloning the Repository – Getting Started

The first thing Maya needs is a local copy of her team’s repository. This is where the git clone command comes in.

Understanding Git Clone

The git clone command creates a complete copy of a remote repository on your local machine. It’s not just downloading files—you’re getting the entire history, all branches, and a connection to the original repository.

Here’s the basic syntax:

git clone <repository-url>

HTTPS vs SSH Cloning: Which Should You Choose?

Maya notices she has two options for cloning the repository:

HTTPS Cloning:

git clone https://github.com/cloudtech-solutions/terraform-infrastructure.git

SSH Cloning:

git clone git@github.com:cloudtech-solutions/terraform-infrastructure.git

When to use HTTPS:

• Quick, one-time access to public repositories
• You don’t want to set up SSH keys
• Working on a shared or temporary machine

When to use SSH:

• Regular development work (recommended for DevOps)
• Enhanced security with key-based authentication
• Seamless authentication without entering credentials repeatedly

For our Git clone example, Maya chooses SSH since she’ll be working with this repository regularly:

git clone git@github.com:cloudtech-solutions/terraform-infrastructure.git
cd terraform-infrastructure

After cloning, Maya can see the repository structure:

terraform-infrastructure/
├── main.tf
├── variables.tf
├── outputs.tf
├── terraform.tfvars.example
└── modules/
    ├── vpc/
    ├── ec2/
    └── rds/

Perfect! She now has a complete local copy of her team’s infrastructure code.

You can also check the official git clone documentation for all available options

Step 2: Making Your First Commit – The Heart of Version Control

Now Maya needs to add her S3 bucket configuration. This is where she’ll learn about the Git commit tutorial process that every DevOps engineer uses daily.

Understanding the Git Workflow

Before Maya makes changes, let’s understand Git’s three-stage workflow:

1. Working Directory: Where you make changes to files
2. Staging Area: Where you prepare changes for commit
3. Repository: Where committed changes are permanently stored

Modifying the Terraform Configuration

Maya opens main.tf and adds her S3 bucket configuration:

# Existing Terraform code...

# New S3 bucket for application logs
resource "aws_s3_bucket" "app_logs" {
  bucket = var.app_logs_bucket_name
  
  tags = {
    Name        = "Application Logs Bucket"
    Environment = var.environment
    ManagedBy   = "Terraform"
  }
}

resource "aws_s3_bucket_versioning" "app_logs_versioning" {
  bucket = aws_s3_bucket.app_logs.id
  versioning_configuration {
    status = "Enabled"
  }
}

She also updates variables.tf to include the new variable:

variable "app_logs_bucket_name" {
  description = "Name of the S3 bucket for application logs"
  type        = string
  default     = "cloudtech-app-logs-prod"
}

If you’d like to explore another practical example, check out my detailed guide on how to launch an EC2 instance with Terraform

The Essential Commit Commands

Now Maya needs to save her changes. Here’s the step-by-step process:

1. Check the status of your changes:

git status

Output:

On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  modified:   main.tf
  modified:   variables.tf

2. Stage your changes:

git add main.tf variables.tf

⚠️ Warning: Avoid using git add . with Terraform projects! This command stages ALL files, including potentially sensitive ones like:

• terraform.tfstate (contains sensitive resource details)
• *.tfvars files (may contain secrets or passwords)
• .terraform/ directory (contains provider credentials)

Always be explicit about which files you’re staging in DevOps work.

3. Commit your changes:

git commit -m "Add S3 bucket for application logs

- Added aws_s3_bucket resource for app logs storage
- Enabled versioning for compliance requirements  
- Added configurable bucket name variable
- Tagged resources according to company standards"

Writing Effective Commit Messages in DevOps

Maya’s commit message follows DevOps best practices:

• Clear subject line (50 characters or less)
• Blank line separating subject from body
• Detailed description of what changed and why
• Bullet points for multiple changes

💡 Pro Tip: In DevOps, your commit messages often trigger automated deployments and become part of change logs. Clear messages help with troubleshooting, rollbacks, and compliance audits.

🔒 Security Alert: Never commit sensitive information like:

• AWS credentials or API keys
• Database passwords
• Private certificates or SSH keys
• Production configuration values

Use environment variables, secret management tools (like AWS Secrets Manager), or encrypted files instead.

Verifying Your Commit

Maya can verify her commit was successful:

git status

Output:

On branch main
Your branch is ahead of 'origin/main' by 1 commit.
nothing to commit, working tree clean

Perfect! Her changes are now safely committed to her local repository.

Step 3: Understanding Git Log – Your DevOps Time Machine

Before Maya pushes her changes, she wants to review what she’s done and understand the recent history of the project. This is where Git log explained becomes invaluable for DevOps work.

Basic Git Log Usage

The simplest way to view commit history:

git log

This shows Maya something like:

commit a7b8c9d... (HEAD -> main)
Author: Maya Rodriguez <maya@cloudtech-solutions.com>
Date:   Thu Aug 28 10:30:15 2025 -0500

    Add S3 bucket for application logs
    
    - Added aws_s3_bucket resource for app logs storage
    - Enabled versioning for compliance requirements
    - Added configurable bucket name variable
    - Tagged resources according to company standards

commit f1e2d3c...
Author: John Smith <john@cloudtech-solutions.com>
Date:   Wed Aug 27 14:20:33 2025 -0500

    Update RDS instance class for production
    
    - Upgraded from db.t3.micro to db.t3.small
    - Improved performance for increased load

Advanced Git Log for DevOps Teams

Maya finds these Git log variations particularly useful for DevOps work:

Compact one-line format:

git log --oneline

Show last 5 commits:

git log -5

Show changes in each commit:

git log -p

💡 Pro Tip: Use git log -p to see exactly what changed in each commit—invaluable for understanding how Terraform resources evolved.

Show commits by specific author:

git log --author="Maya"

Show commits affecting specific files:

git log main.tf

🔍 DevOps Use Case: This last command is incredibly useful when you need to understand how a particular Terraform resource or configuration file has evolved over time.

Using Git Log for DevOps Troubleshooting

Here’s a real-world scenario where Git log saves the day:

Imagine Maya’s team discovers that their staging environment is broken after a recent deployment. Using Git log, she can quickly identify recent changes:

git log --since="2 days ago" --oneline

Output:

a7b8c9d Add S3 bucket for application logs
f1e2d3c Update RDS instance class for production
g3h4i5j Fix security group rules for web servers
k6l7m8n Update Kubernetes deployment replicas

Now Maya can use git show <commit-hash> to examine each change and identify the problematic commit:

git show g3h4i5j

This shows exactly what changed in that commit, helping Maya and her team pinpoint and fix the issue quickly.

Advanced Git Concepts for DevOps Success

Now that Maya has mastered the basics, let’s explore some additional concepts that will make her more effective in her DevOps role.

Branching in DevOps Workflows

Most DevOps teams use branching strategies to manage different environments and features. Maya learns about the common Terraform Git workflow:

# Create a new feature branch
git checkout -b feature/add-s3-logging

# Make changes and commit (as shown above)
git add .
git commit -m "Add S3 bucket for application logs"

# Push to remote repository
git push origin feature/add-s3-logging

Pull Request Workflows in DevOps

After pushing her branch, Maya creates a pull request (PR) in GitHub. This is where Git basics connect to DevOps collaboration:

🔄 DevOps Workflow: Pull requests enable:

• Peer review of infrastructure changes before deployment
• Automated testing with CI/CD pipelines
• Discussion of architectural decisions
• Approval gates for production deployments

Git Tags for Infrastructure Versioning

Maya’s team uses Git tags to mark stable infrastructure versions:

# Create a tag for a release
git tag -a v1.2.0 -m "Production release: Added S3 logging infrastructure"

# Push tags to remote
git push origin --tags

# List all tags
git tag -l

💾 Infrastructure Versioning: Tags enable:

• Rollback to specific infrastructure versions
• Release notes generation from commit messages
• Environment promotion with known-good configurations

Git Hooks for DevOps Automation

Maya discovers her team uses Git hooks for quality control:

# Pre-commit hook example (.git/hooks/pre-commit)
#!/bin/sh
echo "Running Terraform validation..."
terraform fmt -check=true -diff=true
terraform validate
echo "Pre-commit checks passed!"

🔧 Automation Benefits:

• Format validation ensures consistent Terraform code style
• Syntax checking catches errors before commits
• Security scanning prevents credential commits
• Policy validation enforces organizational standards

Working with Remote Repositories

Maya needs to stay synchronized with her team’s work:

# Fetch latest changes from remote
git fetch origin

# Pull latest changes into current branch
git pull origin main

# Push local changes to remote
git push origin main

Handling Terraform-Specific Git Workflows

DevOps teams often have specific workflows for Infrastructure as Code. Here’s what Maya’s team uses:

1. Development branch: For ongoing feature work
2. Staging branch: Automatically deployed to staging environment
3. Main branch: Deployed to production after approval

Maya’s typical workflow:

# Start from latest main
git checkout main
git pull origin main

# Create feature branch
git checkout -b feature/new-s3-bucket

# Make changes, commit
git add .
git commit -m "Add application logging S3 bucket"

# Push and create pull request
git push origin feature/new-s3-bucket

Git Best Practices for DevOps Teams

Based on her team’s experience, Maya learns these essential practices:

1. Commit Early and Often

• Small, focused commits are easier to review and rollback
• Each commit should represent a single logical change

💡 Pro Tip: Think “atomic commits”—each commit should be able to stand alone without breaking functionality.

2. Write Descriptive Commit Messages

• Include the “what” and “why” of changes
• Reference issue numbers or tickets when applicable

3. Use .gitignore Effectively For Terraform projects, Maya’s team ignores:

# .gitignore
*.tfstate
*.tfstate.backup
.terraform/
*.tfvars
.DS_Store

⚠️ Critical: Never commit .tfstate files—they contain sensitive resource information and can cause conflicts in team environments.

4. Review Before You Push Always run these commands before pushing:

git status
git log --oneline -5
git diff origin/main

🔍 DevOps Safety Check: Use git diff to review exactly what you’re about to deploy—this prevents configuration surprises in production.

Troubleshooting Common Git Issues in DevOps

Maya encounters some common situations that every DevOps engineer faces:

Scenario 1: Accidentally Committed Sensitive Data

🚨 Emergency: Maya accidentally committed AWS credentials:

# Remove file from staging area but keep in working directory
git reset HEAD terraform.tfvars

# Remove file completely from the last commit
git reset --soft HEAD~1
git reset HEAD terraform.tfvars
git commit -m "Add S3 bucket for application logs"

⚠️ Important: If you’ve already pushed sensitive data, you’ll need to rotate those credentials immediately and consider using git filter-branch or BFG Repo-Cleaner to remove the data from history.

Scenario 2: Need to Undo Last Commit

🔄 Rollback: Maya realizes she made an error in her Terraform configuration:

# Undo last commit but keep changes in working directory
git reset --soft HEAD~1

# Make corrections and commit again
git add .
git commit -m "Add S3 bucket for application logs (corrected configuration)"

Scenario 3: Viewing Differences Before Committing

🔍 Best Practice: Before committing Terraform changes, Maya always reviews them:

# See what will be committed
git diff --staged

# See differences between working directory and last commit
git diff HEAD

💡 Pro Tip: Use git diff --name-only to quickly see which files changed without seeing all the content differences.

Git Integration with DevOps Tools

Understanding how Git integrates with other DevOps tools makes Maya more effective:

CI/CD Pipeline Integration

Maya’s team’s GitLab CI pipeline automatically:

• Runs terraform validate on every commit
• Executes terraform plan on pull requests
• Applies changes to staging when merged to staging branch
• Deploys to production when merged to main branch

Infrastructure as Code Best Practices

Maya learns that Git enables powerful DevOps practices:

1. Infrastructure Versioning

• Each Git tag represents a specific infrastructure version
• Easy rollbacks to previous infrastructure states

2. Environment Management

• Different branches for different environments
• Controlled promotion of changes through environments

3. Collaboration and Review

• Pull requests for peer review of infrastructure changes
• Automated testing before changes reach production

Git Command Reference for DevOps Engineers

Here’s a quick-reference cheat sheet of all the essential Git commands covered in this guide:

Repository Setup

# Clone a repository (HTTPS)
git clone https://github.com/username/repo-name.git

# Clone a repository (SSH - recommended for regular use)
git clone git@github.com:username/repo-name.git

# Navigate to repository
cd repo-name

Basic Workflow

# Check repository status
git status

# Stage specific files (recommended for DevOps)
git add main.tf variables.tf

# Stage all changes (⚠️ use carefully with Terraform)
git add .

# Commit with message
git commit -m "Your commit message"

# Multi-line commit message
git commit -m "Subject line

- Detailed point 1
- Detailed point 2"

Viewing History

# View commit history
git log

# Compact one-line view
git log --oneline

# Show last N commits
git log -5

# Show changes in commits
git log -p

# Show commits by author
git log --author="AuthorName"

# Show commits affecting specific file
git log filename.tf

# Show commits since date
git log --since="2 days ago"

Branching and Remote Operations

# Create and switch to new branch
git checkout -b feature/branch-name

# Switch to existing branch
git checkout main

# Push to remote repository
git push origin branch-name

# Pull latest changes
git pull origin main

# Fetch without merging
git fetch origin

Inspecting Changes

# Show differences in working directory
git diff

# Show staged changes
git diff --staged

# Show differences between branches
git diff main..feature-branch

# Show which files changed
git diff --name-only

Undoing Changes

# Unstage file (keep changes)
git reset HEAD filename

# Undo last commit (keep changes in working directory)
git reset --soft HEAD~1

# View specific commit
git show commit-hash

DevOps-Specific Commands

# Create and push tags
git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin --tags

# List all tags
git tag -l

# Format Terraform code (if terraform is installed)
terraform fmt

# Validate Terraform syntax
terraform validate

Emergency Commands

# Remove sensitive file from last commit
git reset --soft HEAD~1
git reset HEAD sensitive-file.tfvars
git commit -m "Corrected commit without sensitive data"

# View what would be ignored
git status --ignored

📋 Quick Tips for DevOps:

• Always use git status before committing
• Review changes with git diff --staged before pushing
• Use descriptive commit messages that explain the “why”
• Never commit .tfstate files or credentials
• Create .gitignore files for Terraform projects
• Use branches for feature development
• Tag stable releases for easy rollbacks

Conclusion: Your Git Journey Continues

Mastering Git basics for DevOps is just the beginning of Maya’s journey, and yours too. These fundamental commands—clone, commit, and log—form the foundation of modern DevOps practices.

Let’s recap what we’ve covered:

Git Clone: Your entry point to any DevOps project. Whether you’re working with Terraform configurations, Kubernetes manifests, or CI/CD pipelines, cloning gets you started with a complete local copy of the project history.

Git Commit: The heart of version control. Every infrastructure change, every configuration update, every script improvement gets captured in commits that create an audit trail of your DevOps work.

Git Log: Your time machine and detective tool. When deployments break or configurations need investigation, Git log helps you understand what changed, when, and why.

As you continue your DevOps journey, you’ll discover that Git isn’t just about managing code—it’s about managing change itself. Every successful DevOps team relies on Git to coordinate their work, maintain system reliability, and enable the automation that makes modern infrastructure possible.

Next Steps for DevOps Engineers

Ready to level up your Git skills? Here’s what to explore next:

• Advanced branching strategies (GitFlow, GitHub Flow)
• Git hooks for automating quality checks
• Merging and rebasing for clean project history
• Git submodules for managing complex multi-repository projects
• Integration with CI/CD tools like Jenkins, GitLab CI, or GitHub Actions

Remember, becoming proficient with Git is an investment that pays dividends throughout your entire DevOps career. Every day you’ll use these skills, whether you’re managing a simple Terraform module or orchestrating complex multi-service deployments.

Start practicing with a personal project today, and soon these commands will become second nature. Your future self—and your DevOps team—will thank you for mastering these fundamental skills.

Want to dive deeper into DevOps tooling and best practices? Subscribe to our newsletter and follow @thedevopstooling for more practical tutorials and real-world DevOps scenarios.