Automating the Boring Stuff: When Forgetting to Push Becomes a Thing of the Past

🛠️ Time for an Engineer’s Side Quest!

Welcome to the behind-the-scenes lab—where I share the practical, messy, and sometimes hilarious realities of building this project.

If you landed here after reading my two-part mini-series, Shipping a Blog with Real DevOps (Part 1) and Part 2, welcome to the bonus round. This is where I dig a little deeper into the automation details—just the kind of stuff that makes an engineer’s life easier (and maybe a bit more fun).

You know that sinking feeling when you turn off your computer, walk away, and suddenly remember: “Did I push my latest blog post? What about those notes from this morning?” Yeah, I’ve been there. Too many times.

It’s the kind of small friction that seems trivial until it isn’t. You’re working on something important—maybe a new blog post, project documentation, or just daily notes in Obsidian—and you forget to commit and push. Then your machine is off, you’re away from your desk, and that nagging thought lingers: “Is my work actually backed up?”

☝️ Yes, that’s a right hand on a left arm—AI art is wild sometimes 🙃

The Problem: Manual Backups Are Easy to Forget

Here’s the thing about manual processes: they work great until they don’t. You tell yourself, “I’ll just remember to push before shutting down.” And most days, you do. But then life happens—you’re in a hurry, distracted, tired—and suddenly your latest work is sitting unsynced on a machine that’s already off.

For me, this started as a very specific problem: keeping my daily blog work committed and backed up without manual intervention. I was writing posts, tweaking layouts, updating content—all tracked in git—but I kept forgetting to push at the end of the day. One too many “oh no, did I commit that draft?” moments convinced me there had to be a better way.

But once I had the solution working for the blog, I realized the same friction existed everywhere. Tech notes backed up in GitHub repos, project documentation, configuration files scattered across repositories—each one technically backed up… if I remembered to push. But relying on memory for something this routine? That’s a recipe for eventual failure. Good engineering means removing unnecessary friction, even in your personal workflows.

The Solution: A Tool That Does It for You

So I built sync-repos—a small Bash script that automatically commits and pushes changes in all your git repositories before your computer shuts down. No intervention, no remembering, no panic. You configure which directories to scan, and the tool handles the rest.

The script is dead simple by design. It scans specified folders for git repositories, checks if there are uncommitted changes or unpushed commits, and takes care of them with timestamped commit messages. If there’s nothing to do, it stays silent. If there’s work to sync, it logs what it’s doing and moves on.

But here’s the clever part: it runs as a systemd service triggered before shutdown. That means every time you turn off your computer, your work gets automatically backed up. You don’t have to think about it. You don’t have to remember. It just happens.

How It Actually Works

The tool itself is straightforward—just a Bash script and a systemd unit file. You install it with a simple make install, configure which directories to watch, and you’re done. From that point on, every shutdown triggers the service, which runs the script, processes your repositories, and pushes everything upstream.

You can also run it manually with sync-repos if you want to force a backup without rebooting, or use --dry-run to see what it would do without actually changing anything. There’s even a --show-logs option to review what’s been backed up recently. It’s designed to be unobtrusive but transparent—you can ignore it completely, or dig into the details whenever you need them.

The configuration is flexible, too. You can set it up system-wide in /etc/sync-repos/directories or per-user in ~/.config/sync-repos/directories. This makes it easy to use on personal machines or shared environments without stepping on anyone’s toes. And because it’s just a Bash script, it’s easy to tweak if you have specific needs.

Why This Matters for Engineers

This isn’t just about backing up blog posts. It’s about reducing cognitive load. Every manual task you have to remember is a tiny tax on your attention. Over time, those taxes add up. The best engineers I know don’t just write good code—they also automate the boring stuff so they can focus on what actually matters.

In the case of sync-repos, the boring stuff is remembering to run git push. It’s trivial in isolation, but when you’re juggling multiple projects, documentation, notes, and a blog, it becomes just one more thing to track. Automating it means one less thing to think about, one less chance for human error, and one more process that just works in the background.

This is also why I find DevOps principles so compelling. It’s not just about deploying web apps or managing infrastructure. It’s about treating your entire workflow—personal or professional—as something that can be made more reliable, more repeatable, and ultimately more humane. Good automation doesn’t replace human judgment; it frees you to use your judgment where it actually counts.

Building for Others, Not Just Yourself

When I first wrote this tool, it was purely selfish—I needed it to keep my blog work backed up daily. But as I started using it for other repos—tech notes, documentation, side projects—I realized: other people probably have this problem too. So I made sure it was configurable, documented, and easy to install. The README explains everything, there’s a contributing guide for anyone who wants to improve it, and the whole thing is MIT-licensed. If it solves a problem for someone else, great. If not, at least it’s one less thing I have to remember.

The feedback loop is what makes open source rewarding. Someone might suggest a feature, find a bug, or just say “this saved me from losing work.” That’s worth more than perfect code. It’s about solving real problems for real people—even if the problem is as mundane as “I forgot to push again.”

The Bigger Lesson: Automate the Friction

The real takeaway here isn’t about git or systemd or Bash scripts. It’s about recognizing unnecessary friction in your workflow and doing something about it. Maybe for you it’s not git backups—maybe it’s repetitive file renames, or deployment steps you keep doing manually, or log files you always forget to rotate.

This automation-first approach—building scripts that handle the boring, error-prone work—became the foundation for something bigger. A few weeks later, I’d find myself at a crossroads: chase Kubernetes for resume appeal, or double down on this kind of repeatable, well-tested automation. But that decision, and what it taught me about production engineering maturity, is a story for a future post.

Whatever it is, always ask yourself: “Could this be automated?” And if the answer is yes, even partially, it’s worth the time investment. The upfront cost of writing a script or configuring a service pays dividends every single time you don’t have to think about it again. That’s the engineer’s mindset: not just solving problems, but removing them entirely when possible.

If you’re curious about the tool, check it out at github.com/jerosanchez/sync-repos. It’s simple, it’s open source, and if it saves you even one “oh crap, did I push that?” moment, it’s done its job. And if you have ideas for improving it—or just want to share your own workflow automation wins—feedback is always welcome.

For me, this is just one more step in making software engineering less about remembering trivia and more about building things that matter. One less manual task, one more reliable process, one step closer to a workflow that just works.