Git for System Administrators

Git for System Administrators

Git is not just a developer tool — it is the foundation of modern infrastructure management. Every Ansible playbook, Terraform configuration, nginx config, and shell script you write should live in a git repository. Git gives you a complete history of every change (who changed what, when, and why), the ability to roll back a broken configuration, and a review process for changes before they hit production. Treating infrastructure as code starts with tracking it in git.

Why git for sysadmins?

Daily git workflow

# Initial setup (one time):
git config --global user.name "Irfan Aslam"
git config --global user.email "irfan@example.com"
git config --global core.editor nano

# Initialize a new infrastructure repo:
mkdir infra-configs && cd infra-configs
git init
git remote add origin git@github.com:yourorg/infra-configs.git

# Daily workflow:
git status              # What changed?
git diff                # What specifically changed?
git add nginx.conf      # Stage specific file
git add ansible/        # Stage directory
git commit -m "nginx: increase worker_processes to 4 for 8-core server"
git push origin main

# Essential git commands for sysadmins:
git log --oneline -20               # Last 20 commits (compact)
git log --follow -p nginx.conf      # Full history of one file (all changes)
git show HEAD~2                     # Show changes in commit 2 back
git blame nginx.conf                # Who wrote each line and when
git diff HEAD~1 HEAD nginx.conf     # What changed in this file last commit
git stash                           # Save uncommitted changes temporarily
git stash pop                       # Restore stashed changes

Managing configuration files

# Track /etc configuration with etckeeper (auto-commits /etc changes):
sudo apt install -y etckeeper
sudo etckeeper init
sudo etckeeper commit "Initial /etc snapshot"
# etckeeper auto-commits /etc before and after apt installs

# .gitignore for infrastructure repos:
cat > .gitignore << 'EOF'
# Secrets (never commit these)
*.pem
*.key
id_rsa
id_ed25519
.env
vault_password_file
secrets.yml

# Terraform state (contains sensitive data)
*.tfstate
*.tfstate.backup
.terraform/

# OS and editor files
.DS_Store
*.swp
*~
EOF

⚠️ WARNING: Never commit private keys, passwords, or secrets to git — even in private repositories. Use Ansible Vault, HashiCorp Vault, or environment variables for secrets. Once a secret is in git history, it must be considered compromised even after deletion.

Branching for infrastructure changes

# Simple branching workflow for infrastructure:
# main     → current production state
# dev      → testing changes before production
# feature/nginx-upgrade → specific change branch

# Make a change:
git checkout -b feature/nginx-1.25-upgrade
# ... edit files ...
git add nginx/
git commit -m "nginx: upgrade to 1.25 for HTTP/2 improvements"
git push origin feature/nginx-1.25-upgrade
# Open pull request → review → merge to main → apply to production

# Emergency hotfix:
git checkout main
git checkout -b hotfix/firewall-rule-correction
# ... fix the issue ...
git commit -m "firewall: allow port 443 on web tier (was accidentally blocked)"
git push && # merge immediately

Conclusion

The minimum viable git practice for sysadmins: create one repository per service or per server role, track all configuration files in it, and write descriptive commit messages explaining WHY the change was made (not what — the diff shows what). A commit message of "fix nginx" tells you nothing in six months. "nginx: increase client_max_body_size to 100MB for file upload API" tells you everything you need to understand, audit, and roll back the change.