Home / DevOps / Git Mastery / Workflow Basics

Git Workflow Basics: Three States for DevOps

10 min read
Git Fundamentals
Updated: March 2024

📌 DevOps Core Concept

Understanding Git's three states (Working Directory → Staging Area → Repository) is fundamental to managing infrastructure code, configuration files, and deployment scripts efficiently.

Working Directory

Where you edit files (Terraform, Ansible, Docker, etc.)

# Your actual files
terraform/
ansible/
docker-compose.yml
→

Staging Area

Preview area for changes before committing

git add terraform/main.tf
git add docker-compose.yml
# Changes ready to commit
→

Repository

Permanent storage of commits (local .git folder)

git commit -m "Add infra"
# Commits stored here
.git/

Understanding Git's Three States

1. Working Directory (Your Files)

This is where you actually work with files. In DevOps, these are your:

  • Terraform configuration files (.tf files)
  • Ansible playbooks (.yml files)
  • Dockerfiles and docker-compose.yml
  • Kubernetes manifests (.yaml files)
  • CI/CD pipeline scripts (Jenkinsfile, .gitlab-ci.yml)
  • Configuration files and scripts
# Typical DevOps working directory structure
infrastructure/
├── terraform/
├── ansible/
├── kubernetes/
├── docker/
└── scripts/
# These are all in Working Directory

2. Staging Area (Index) - Git's Unique Feature

The staging area is like a "preview" or "shopping cart" for your changes. You decide which changes go into the next commit.

🔧 DevOps Example: Selective Staging

You modified 3 files but only want to commit 2 related changes:

git status
# Modified: terraform/main.tf, ansible/nginx.yml, README.md

# Stage only infrastructure changes
git add terraform/main.tf
git add ansible/nginx.yml

# README.md stays in Working Directory
# Commit will only include staged files

3. Repository (.git directory)

This is where Git stores all commits permanently. Each commit is a snapshot of your entire project at a point in time.

# After staging, commit to repository
git commit -m "Update infrastructure: Add load balancer config"

# This creates a permanent commit in the repository
# Commit hash: abc123def456...

🎯 Git Workflow Visualization

Click each step to see the command:

Working Directory

Edit infrastructure files

Click to see example
→

git add

Stage selected changes

Click to see example
→

Staging Area

Changes ready to commit

Click to see example
→

git commit

Create permanent snapshot

Click to see example
→

Repository

Commits stored permanently

Click to see example

Complete Workflow Example for DevOps

📋 Infrastructure Change Workflow

1
Start in Working Directory
Edit Terraform configuration for new VPC
vim terraform/vpc.tf
# Add VPC configuration
2
Check Status
See what changed in your infrastructure
git status
# Shows: terraform/vpc.tf (modified)
3
Stage Changes
Add specific infrastructure changes to staging
git add terraform/vpc.tf
# Moves to Staging Area
4
Review Staged Changes
Check what's about to be committed
git diff --staged
# Preview the VPC configuration
5
Commit to Repository
Create permanent snapshot of infrastructure
git commit -m "terraform: add VPC configuration for production"
# Creates commit in local repository
6
Push to Remote
Share infrastructure changes with team/CI/CD
git push origin main
# Triggers CI/CD pipeline

Why Three States Matter for DevOps

State DevOps Purpose Common Commands Best Practices
Working Directory Edit infrastructure code, test configurations vim, nano, IDE edits Test changes locally before staging
Staging Area Review and organize changes before committing git add, git reset Stage related changes together
Repository Store approved infrastructure versions git commit, git log Atomic commits with clear messages

💡 DevOps Staging Strategy

Atomic Commits: Stage and commit related changes together (e.g., all Terraform files for one feature)
Selective Staging: Use git add -p to stage specific parts of a file
Review Before Commit: Always check git diff --staged before committing infrastructure changes
Clear Messages: Use format: component: description (terraform:, ansible:, docker:)

Common Scenarios & Solutions

Scenario 1: Accidentally staged wrong file

# Remove from staging (keeps in working directory)
git reset HEAD terraform/wrong-file.tf
# File returns to Working Directory, unstaged

Scenario 2: Want to un-modify a file

# Discard changes in Working Directory
git checkout -- ansible/playbook.yml
# WARNING: This permanently discards uncommitted changes!

Scenario 3: See differences between states

# Working Directory vs Staging
git diff

# Staging vs Repository
git diff --staged

# Working Directory vs Repository
git diff HEAD

Frequently Asked Questions (FAQ)

Why does Git have a staging area? Can't I just commit directly?

The staging area is Git's killer feature! It allows:

1. Selective commits: You modified 5 files but only want to commit 3 related changes
2. Review before commit: See exactly what will be committed
3. Split changes: Separate logical changes into different commits
4. Partial staging: Stage only specific changes within a file (git add -p)

For DevOps: This is crucial when you have multiple infrastructure changes but want to commit them logically.

What's the difference between git add . and git add -A?

git add . - Stages new and modified files in current directory and subdirectories
git add -A - Stages ALL changes: new, modified, AND deleted files from entire working tree

DevOps example:
If you deleted a old Terraform file and created a new one:
• git add . stages only the new file
• git add -A stages both the new file AND records the deletion

Usually git add . is sufficient for daily DevOps work.

How do I see what's in the staging area vs what's not staged?

git status shows both:
• Changes to be committed (staging area)
• Changes not staged for commit (working directory)

More detailed view:
git diff - Shows unstaged changes (WD vs Staging)
git diff --staged - Shows staged changes (Staging vs Repo)
git diff HEAD - Shows all changes (WD vs Repo)

For DevOps: Always check git diff --staged before committing infrastructure changes!

Can I skip the staging area and commit directly?

Yes, but not recommended! You can use:
git commit -a -m "message"
This stages ALL modified files and commits in one command.

Why it's bad for DevOps:
1. No chance to review changes before commit
2. Can't commit selectively (commits everything)
3. Easy to commit debug code or temporary changes
4. Hard to create atomic, logical commits

Always use staging area for infrastructure code - it's a safety net!

What happens to the staging area after I commit?

The staging area becomes empty after a successful commit.

Workflow:
1. You stage changes: git add file1 file2
2. You commit: git commit -m "message"
3. Staging area is now empty
4. Working directory may still have unstaged changes

DevOps tip: After committing infrastructure changes, check git status to see if anything remains unstaged that should be in the next commit.

How do I stage only part of a file (partial staging)?

Use git add -p (patch mode):

git add -p terraform/main.tf

Git will show each change ("hunk") and ask:
• y - stage this hunk
• n - don't stage this hunk
• q - quit
• s - split into smaller hunks
• e - manually edit the hunk

DevOps use case: When your Terraform file has both production and debugging changes, but you only want to commit production changes.

Where is the staging area actually stored?

The staging area (also called "index") is stored in the .git/index file.

Location: .git/index in your repository

What's in it:
• List of files that will go into next commit
• SHA-1 hashes of file contents
• File permissions and timestamps

DevOps insight: You generally don't need to touch this file directly, but it's good to know where Git stores staging information. The index is binary, so view it with git ls-files --stage if curious.

Previous: Basic Commands Next: Branching Strategies

Related Articles