After setting up my Raspberry Pi home lab, I deployed a small project onto one of the Pis and immediately wanted a cleaner method for continuous deployment. The app lived in a Git repository, and I wanted the running copy on the Pi to update automatically whenever the repo changed.
The obvious approach would have been a webhook: GitHub sends a request, a local service receives it, and the Pi pulls the latest code. I decided against that for security reasons. I did not want to expose a service on my home network just so GitHub could tell it that a commit had landed, and I did not want to build a tunnel or webhook receiver for something that could be solved more simply.
I wrote git-auto-sync as a pull-based alternative. It installs as a user-level systemd service and timer, periodically fetches the configured remote branch, fast-forwards the local checkout when there is a newer commit, and then runs a configurable deployment command such as docker compose up -d --build.
The important part is that it is deliberately conservative. It refuses to overwrite tracked local changes, refuses local-only commits, only allows fast-forward updates, and uses flock to prevent overlapping runs. If the deployment command fails after an update, it records that pending deployment and retries it on the next timer run rather than silently moving on.
That made it a good fit for my home server setup: the Pi only needs outbound Git access, the deployment logic is visible in one small shell tool, and the operational state is handled by systemd logs and timers. It is not meant to be a full CI/CD platform, but for small self-hosted services it gives me the automation I wanted without adding an inbound security surface to my LAN.