Site Icon Skiddish

Using Git Without Losing Your Mind in a Homelab

 Tutorials  5 mins

Introduction

Git has a bit of a branding problem.

Ask around and you’ll hear about rebases, detached HEAD states, force pushes, merge strategies, protected branches, signed commits, and enough other crap to make it sound like version control is a hobby in its own right. For a solo homelabber, that’s mostly noise. You do not need to become a Git mystic to get real value out of it.

What you actually need is a simple habit for making changes without losing work, breaking history, or forgetting what you changed three weeks ago when a service falls over.

That’s the real win.

Why Git Is So Useful in a Homelab

A homelab is full of tiny infrastructure decisions that seem obvious at the time and deeply mysterious later on.

Why did I rename that host? Why is this compose file different from the other one? When did I swap that port? Which version of the config actually worked?

Git gives you a record of those decisions. More importantly, it gives you a safe way to experiment. You can change a playbook, rewrite a service config, or refactor a documentation page knowing that you can inspect exactly what changed before committing it.

That alone is worth the price of admission.

My Preferred Solo Workflow

When I’m working alone, I like the workflow to be boring and easy to remember:

  1. pull the latest changes
  2. make the change
  3. inspect the diff
  4. commit one coherent chunk
  5. push it

That usually looks like this:

1
2
3
4
5
6

git pull --rebase
git status
git diff
git add <files>
git commit -m "short, specific summary"
git push

The important thing isn’t the exact command order so much as the rhythm behind it.

git status keeps you honest. git diff stops you from committing nonsense. Small commits make future-you much less angry.

If I’ve made a few unrelated changes at once, I try to split them into separate commits instead of shoving everything into one comingled mess. That doesn’t need to become a religious practice, but it does help massively when you’re tracking down regressions later.

Keep Commits Boring and Specific

Good commit messages are not literature. They are tiny labels for future archaeology.

These are useful:

  • ansible: add forgejo public ssh example
  • blog: add forgejo deploy workflow
  • docs: clarify vps rebuild order

These are much less useful:

  • updates
  • fix stuff
  • more changes

The point is not elegance. The point is being able to glance at the history and immediately understand what happened.

Branches for Solo Work

If I’m doing a small safe change, I’m perfectly happy to work directly on main.

If the change is messier, riskier, or likely to span a while, I make a branch:

1

git switch -c improve-netbird-docs

Then I work normally, commit as I go, and merge it back when I’m done.

Branches are useful because they let you separate “I’m trying something” from “this is the version I trust.” In a homelab, that separation is often enough to stop you from deploying half-finished ideas out of impatience.

A Simple Small-Team Workflow

When more than one person is touching the same repo, the main thing you want is less surprise.

You do not need a giant corporate Git policy for that. You mostly just need a few rules:

  • pull before you start
  • use a branch for each change
  • keep commits focused
  • let other people read the diff before merge when the change matters
  • avoid force-pushing shared branches unless everyone understands why

In practice, a small-team flow looks like:

1
2
3
4
5
6

git pull --rebase
git switch -c fix-prometheus-alert-copy
# make changes
git add <files>
git commit -m "docs: clarify prometheus alert wording"
git push -u origin fix-prometheus-alert-copy

Then open a pull request and let someone else sanity-check it.

That review does not need to be dramatic. Half the value is simply giving another human the chance to notice “this looks fine, but why are we also changing that unrelated file?”

Rebase Versus Merge, Without the Drama

For most small homelab repos, I think git pull --rebase is a good default because it keeps your local work sitting neatly on top of the newest remote changes.

If a push gets rejected, the usual fix is simply:

1
2

git pull --rebase
git push

That covers a surprising amount of real life.

You can absolutely learn the deeper theory later, but you don’t need to front-load every Git concept before becoming productive.

The Real Trick

The real trick with Git is not mastering every command.

It’s building the habit of checking your work before you record it.

If you consistently use git status, read your diffs, write clear commit messages, and avoid bundling unrelated changes together, you’re already doing the part that matters. Everything else is just more advanced tooling around that core discipline.

Closing Thoughts

Git is at its best when it fades into the background.

For a solo homelabber, that means a lightweight workflow that helps you move fast without becoming sloppy. For a small team, it means using branches and review just enough to prevent confusion without burying simple work under ceremony.

Keep it simple, keep it inspectable, and let the history do its job.

See Also: