Git basics for infrastructure and configuration management
The core workflow — clone, status, add, commit, push, pull — applied to config and scripts, not application code. · 9 min
Git tracks changes to files over time, and for a sysadmin, the files worth tracking are configuration files, automation scripts, and infrastructure-as-code definitions (like Ansible playbooks, covered next level) — not necessarily application source code. The core everyday cycle: `git clone` copies an existing repository locally; `git status` shows what's changed since the last commit; `git add` stages specific changes to be included in the next commit; `git commit -m "message"` saves a snapshot with a description; `git push` sends committed changes to a remote repository (GitHub, GitLab, or a private server); `git pull` fetches and merges changes others have pushed.
The practical payoff over ad-hoc editing directly on a server: every change has a timestamped, attributed history — who changed what, when, and (via the commit message) why. A bad configuration change can be reverted to exactly the last-known-good state with `git revert` or `git checkout` on a specific commit, instead of trying to remember or reconstruct what the file looked like before. Multiple administrators working on the same configuration repository can see each other's changes and avoid silently overwriting each other's work, which happens constantly with direct, untracked editing on shared systems.
Branches let you test a configuration change in isolation before it affects the version everyone else uses: `git checkout -b test-change` creates and switches to a new branch, changes made there don't affect the main branch until explicitly merged back (`git merge`), and if the change turns out to be wrong, the branch can simply be discarded with zero impact on the working configuration everyone else relies on.
| Command | Purpose | Example |
|---|---|---|
| git clone url | Copy a remote repository to your local machine | — |
| git status | Show what has changed since the last commit | — |
| git add file | Stage a change to be included in the next commit | git add nginx.conf |
| git commit -m "message" | Save a snapshot of staged changes with a description | — |
| git push | Send local commits to the remote repository | — |
| git pull | Fetch and merge remote changes into your local branch | — |
| git log --oneline | View commit history in a compact, one-line-per-commit format | — |
| git checkout -b branch-name | Create and switch to a new branch | — |
A typical configuration-change workflow
$ git checkout -b fix-nginx-ratelimit
$ vim nginx.conf # make the change
$ git diff # review exactly what changed
$ git add nginx.conf
$ git commit -m "Add rate limiting to /api endpoint"
$ git push origin fix-nginx-ratelimit
# Open a pull/merge request for review before merging to mainCommon Mistakes
- ⚠ Editing configuration directly on a production server and never committing the change anywhere — the next person to touch that file has no idea what changed or why
- ⚠ Committing directly to a main/production branch without review, for anything beyond a trivial or emergency fix
- ⚠ Writing a commit message like "fix stuff" instead of describing what changed and why — this defeats the entire point of having history
Takeaway: Configuration and scripts under version control give you exactly what ad-hoc editing never does: a reviewable, attributable, revertible history of every change — treat infrastructure config the same way you'd treat code.