`apt install etckeeper` will setup a repo in /etc/.git for you. It tracks any changes made via apt, and it runs nightly for other changes.

On your primary repo, create dirs for each machine e.g.

  monorepo/
  ├─ Machine1/
  │  ├─ usr/share/www/
  │  ├─ etc/
  ├─ machine2/
  │  ├─ etc/

Create remotes for each machine+repo e.g. `git remote add hosts/machine1/etc ssh://machine1/etc` then `git fetch hosts/machine1/etc`

Then add the subtree with `git subtree add -P machine1/etc hosts/machine1/etc master`

When you want to pull changes you can `git subtree pull` or `git subtree push …`

If you end up making changes in your monorepo, use push. If you make changes directly on the machine (or via terraform), pull

This way you can edit and manage dozens of machines using a single git repo, and git subtree push to deploy the changes. No deploy scripts.

Thanks, this sounds interesting. I wasn’t aware of etckeeper. So I take it you do periodic git pulls to update files and keep it all in check.

The idea of a folder per machine is very good.

That’s right and git helps with that too, like any repo. It will warn you when the target is dirty , or you haven’t pulled the latest changes. So you don’t need to do the mental bookkeeping.

And let me know what you end up doing with it. I’ve been thinking about making an “unconventional git patterns” site because I love it so much and it’s so under-utilized.

I call it “fan out” because it allows one repo to fan out to many deployments. The monorepo can be pushed to GitHub/gitlab and backed up regularly. It’s a lot easier to manage one big repo than dozens of tiny ones. And it helps with dependencies across machines. You can version control the entire network using the repo git commit.