In this day and age, the line between a Developer (Dev) and an Administrator (Ops) has finally blurred. If your scripts only live on your desktop or in ~/scripts/, you are working inefficiently.

Everything from “one-liner” Bash scripts and Python automation to massive Ansible playbooks or Terraform manifests must be under the control of a Version Control System (VCS).

Benefits of Using a VCS#

Every admin has the right to make a mistake. We are human, and errors happen. To mitigate or even prevent critical situations, you must be able to roll back to a known working state using git revert.

With change logging, you will always know who, when, and most importantly why a parameter was changed in an Nginx, Apache, or Bind9 config. Working in a team of several admins? Multiple people can work on the same project without overwriting each other’s changes.

Furthermore, VCS is the first step toward automation (CI/CD). A commit to a repository can automatically update configurations across hundreds of servers.

Tools Overview: From Classics to the Exotic#

1. Git - The De Facto Standard#

Today, Git is the foundation. If you don’t know git push, you are out of the market.

  • Pros: Decentralization, speed, a massive community, and support by any IDE.
  • Cons: Learning curve. Working with branches might seem complex at first.
  • Best for: Everything and everyone, from personal notes to Infrastructure as Code (IaC).

2. Subversion (SVN) - The Old Guard#

A centralized system that was once king. Now it is mostly found in legacy projects or very specific corporate environments.

  • Pros: Simple model with one central repository.
  • Cons: Requires a constant connection to the server; slow branching.

3. Mercurial (Hg) - The Friendly Face#

Similar to Git but with a more “human” interface. It was popular but lost the marketing war.

  • Pros: More intuitive commands compared to Git.
  • Cons: Smaller ecosystem; harder to find ready-made integrations.

4. Darcs - An Alternative View#

While Git and SVN operate on the concept of “snapshots,” Darcs is based on a unique Theory of Patches.

  • Pros: Incredible flexibility. You can choose which specific changes (patches) to add to the repository without worrying about their strict order.
  • Cons: Written in Haskell, which makes it niche. Performance on very large projects lags behind Git.
  • Best for: Aesthetic-driven admins and specific local projects.

Moving forward, we will focus on Git, the most widely used VCS.

Where to Host Your Code? Git is Not Just the “Cloud”#

Many beginners believe that Git necessarily requires a web interface like GitHub or GitLab. This is a myth. You can deploy Git hosting in 5 minutes without any web server.

  1. Git via SSH (Self-hosted): All you need is access to any server. Just initialize a bare repository on the server with git init --bare /srv/git/project.git, and your entire team can push to it. This is highly secure, free, and completely under your control.

  2. File Shares (NFS/SMB): A repository can live right on a network drive. Although this is less reliable due to potential file-locking conflicts, it remains a viable “quick backup” option for a solo admin.

  3. Dedicated Platforms:

  • GitHub - for open-source and personal projects.
  • GitLab - the enterprise standard with powerful built-in CI/CD.
  • Gitea / Forgejo - lightweight self-hosted tools written in Go that run smoothly even on microcomputers.

Cheat Sheet: The “Combat Set” of Git Commands#

This list covers 90% of a sysadmin’s daily tasks.

Getting Started#

  • git init - create a new repository in the current folder.
  • git clone [url] - copy an existing project (e.g., git clone ssh://user@server:/srv/git/repo.git).

Managing Changes#

  • git status - the most important command. Shows which files are modified and which are not yet tracked.
  • git add script.sh - add a file to the “index” and stage it for saving.
  • git commit -m "feat: add log rotation to backup script" - record changes in the history with a comment.

Working with Remote Servers#

  • git remote add origin [url] - link your local repository to a server.
  • git push origin main - send your local commits to the server.
  • git pull - fetch and merge the latest changes from your colleagues.

If Something Goes Wrong#

  • git diff - see exactly what you changed in the code compared to the last version.
  • git checkout -- config.conf - discard all unstaged changes in a file and revert to the last commit.
  • git log - view the history of all previous edits.

Repository Hygiene: Configuring File Exclusions#

A real admin never pulls junk into Git. Temporary files, logs, cache, and especially passwords must stay out. For this, create a .gitignore file in the project root.

Example .gitignore for a SysAdmin automating with Bash, Python, and Ansible:

# --- System logs and temporary files ---
*.log
*.tmp
*.swp
.DS_Store
thumbs.db

# --- Python compilation and environments ---
__pycache__/
*.pyc
*.pyo
*.pyd
.venv/
venv/
ENV/

# --- Ansible junk ---
*.retry
.ansible_cache/

# --- Terraform temporary files ---
.terraform/
*.tfstate
*.tfstate.backup
.terraform.tfstate.lock.info

# --- SECRETS (Never push these!) ---
*.pem
*.key
*.pub
id_rsa
secrets.txt
.env

Pro-Tips: How Not to Shoot Yourself in the Foot#

  1. Atomic Commits: One commit equals one task. Don’t mix a core project update with a comment change in a backup script in a single entry.
  2. Meaningful Messages: Forget about “fix,” “update,” or “111.” A month from now, you won’t remember what happened. Use the Conventional Commits standard:
# examples
# feat: (Feature) adding new functionality
feat: add firewall rules for web-server
# fix: (Bug Fix) fixing an error
fix: correct mysql backup path.
# docs: (Documentation) changes in documentation or README
docs: update installation steps
# refactor: (Refactoring) rewriting code without changing its logic
refactor: optimize loops in cleanup script
# chore: (Routine/Tasks) technical tasks that don't change the script's logic
chore: add tmp files to .gitignore
  1. Don’t store secrets! If you need to encrypt passwords in Ansible, use ansible-vault. If you use scripts, move them to .env file, which should be in your .gitignore.

Conclusion of our review#

Don’t try to learn everything at once. Start with the “holy trinity”: add -> commit -> push. The first time you accidentally delete a critical script and recover it from Git in 2 seconds, you’ll understand why this tool is the industry standard.

Git is as essential as SSH or a text editor. Start small by creating a local repository for your bash scripts today. Your “future self” will thank you during the next 3 AM incident.