Keeping the Repo Safe
Sep 2026
This one is about keeping your project going when things don't go as planned.
At first, GitHub was simply how (and where) I kept the repository up to date. I would commit when I had a meaningful change, push to origin on every commit, and treat the remote as the place where the work lived.
This was also ideal for my two-device setup: I could start the work on my office desktop, commit and update GitHub on reaching a WIP milestone, and resume on my laptop by fetching the latest commits from GitHub.That is a perfectly viable and recommended way to work with software repos. But it also has a flaw, which eventually pushed me toward a two-pronged approach.
Over the past few months, I have come to learn that it is not wise to rely on a single service for everything. If an account is suspended, frozen or temporarily restricted (as happened to me!), and your workflow depends entirely on that one platform, then the project is more fragile than it appears to be.
Sync vs Backup
| Purpose | GitHub Sync | Backup (GDrive) |
|---|---|---|
| Primary Role | Keeps your repo current and versioned | Preserves a second copy of your work |
| Best Uses | Daily writing, commits, branches, collaboration | Recovery from loss, corruption, or service disruption |
| Benefits | Clear history and easy sharing | Redundancy outside the main workflow |
| Assumptions | The service remains available and healthy | The service may fail or be restricted |
| Good Practices | Commit and push regularly | Keep an independent backup path running |
The important point is not that one is better than the other. They serve different layers of reliability. GitHub is where I maintain the active project history. My backup is the insurance policy when the usual path is interrupted.
What works for me
I try to keep the process intentionally small:
- Commit every time a meaningful change is completed
- Push to GitHub on a regular rhythm, not just when something feels urgent
- Treat the project repo as a system, not just a folder on a laptop
- Keep an independent backup schedule running for the repo itself
It's not about over-engineering, but about recognising that your work should not live only in one place.
For me, that means GitHub remains the active version-control layer, while a separate scheduled zip archive and GDrive sync act as the redundant backup layer. The two processes complement each other, and are not interchangeable.
I also maintain operational awareness of the workflows, and have oversight by way of log files as well as periodic 'look-ins' to ensure the the machinery is working as planned.
The exact tools are less important than the approach: No one platform is enough.
Why this matters
This two-pronged approach has become a part of how I think about all my personal projects now.
A repository is not just a place where your code files accumulate - it is an operational system that needs continuity and reliability. The goal is not to be dramatic about every failure, but reduce friction as much as avoidable. And, a second line of defence is partly a technical habit and partly a design choice. It is the difference between building something that works on a good day, and building something that can survive a bad week.
That is why I keep GitHub sync and GDrive backup alongside each other. One keeps the work moving, while the other keeps the work recoverable.
This project captures ideas, decisions, and lessons I’ve learned while building with AI. It aims to help non-technical users understand and use these tools effectively. I also use AI at times to improve or refine the content.
Readers should use the commands and instructions here with care. The creator accepts no responsibility for system damage, data loss or other consequences resulting from their use.