A local Git repository is not a backup when it lives on the same laptop as the working files. A failed SSD, a stolen bag, ransomware, or an accidental rm -rf can wipe out both the current code and its local history. A usable backup keeps independent, recoverable copies of the files, history, configuration, and essential documentation.
For developers, copying a project folder is not enough. You need to be able to rebuild, understand, and restore the project without exposing source code, credentials, customer data, or private keys.
Separate version control from backup
Git and backups solve different problems. Git records changes, supports branches, and lets you inspect or reverse individual commits. It does not protect you if every copy of the repository is lost. A repository with one clone still has one point of failure.
A remote Git host provides an off-device copy and is useful for collaboration, but it should not be your only backup. Accounts can be locked, repositories can be deleted, permissions can change, and a mistaken force push can spread unwanted history. Important work needs an independent backup that you control separately from the day-to-day remote.
| Tool or copy | Primary purpose | What it may not protect against alone |
|---|---|---|
| Local Git repository | Track file history and branches | Device loss, disk failure, ransomware |
| Remote Git repository | Collaboration and off-device repository copy | Account loss, remote deletion, bad changes synced upstream |
| Backup archive | Independent point-in-time recovery | Fine-grained development workflow |
| Encrypted offline copy | Recovery during account or cloud problems | Immediate access if stored away from the device |
Use the 3-2-1 idea for project data
The 3-2-1 rule is a practical starting point: keep three copies of important data, on two different types of storage, with one copy off-site. For a personal code project, that might be:
- the active working copy on your computer;
- a private remote repository or encrypted cloud backup;
- an encrypted backup on an external drive stored separately from the computer.
Using different storage types matters because a single event can affect an entire device or service. An external SSD that stays plugged into the same laptop is convenient, but malware or a power event may affect both. Disconnect the drive after a backup, or use backup software that keeps versioned snapshots protected from ordinary deletion.
Off-site storage does not require elaborate infrastructure. It can be an encrypted drive kept in another secure location or a reputable storage service protected with strong account security. What matters is independence: a fire, theft, or disk failure in one location should not destroy every copy.
Know exactly what belongs in a code backup
Source files are only part of a recoverable project. A restore can fail, or take far longer than expected, when build settings, environment definitions, deployment notes, or database schema changes are missing.
Usually safe and necessary to include
- Source code, tests, documentation, and scripts
- Git metadata, including the hidden
.gitdirectory, when creating a full local archive - Build and dependency manifests such as
package.json,pom.xml,build.gradle,requirements.txt, or lock files - Container and infrastructure definitions, such as Dockerfiles and approved infrastructure-as-code files
- Database migrations, seed data that is safe to retain, and local development setup instructions
- Editor settings that the team intentionally shares, provided they do not contain sensitive paths or tokens
Handle these items separately or exclude them
- Secrets: API keys, passwords, private certificates, SSH private keys, and production environment files should not go into a normal repository or casual archive.
- Generated dependencies: folders such as
node_modules, build outputs, and caches can usually be rebuilt from manifests. Backing them up can waste storage and retain vulnerable or unnecessary files. - Real personal or customer data: use sanitized development data where possible. If retention is necessary, encrypt it, limit access, and follow applicable organizational and legal requirements.
- Large binary assets: decide whether they belong in a dedicated asset store, a Git LFS-style workflow, or a separate backup set with clear restore instructions.
A .gitignore file helps, but ignored files may still matter to your local setup. Keep a separate inventory of what is intentionally excluded and how it can be restored. For example, a .env.example file can list required variable names without storing their values.
Protect secrets before copying anything
Backups create more copies by design. If an archive contains a cloud token or private key, every copy becomes another location that needs protection. Before the first backup, and regularly afterward, check the project for files that commonly hold secrets: .env files, credential JSON files, private keys, configuration exports, and old deployment scripts.
Do not trust filenames alone. A token pasted into source code, a commit message, a terminal log, or documentation can end up in Git history and backup snapshots. If a secret is exposed, revoke or rotate it first. Removing the line from the latest version may not remove it from earlier commits or existing archives.
Store secrets in an approved password manager, secrets manager, or encrypted local mechanism suitable for the project. Keep recovery notes separate from the secret values: document which service provides each credential, who may access it, and how to generate a replacement.
Choose backup methods that fit the project
Small learning projects can be covered by a private remote repository and periodic encrypted archives. A team project with releases, databases, and deployment configuration needs a clearer policy for retention, access control, and restore testing.
Private Git remotes
Push commits to a private remote regularly, and protect the account with a unique password and multi-factor authentication. Check repository visibility after creating it. A public repository is not an appropriate backup destination for code containing proprietary material or data. Use branch protection against accidental deletion when your platform supports it, but keep separate archives as well.
For another Git-focused copy, a mirror or bare repository can preserve all refs and history. This is helpful when moving between hosts or maintaining an organization-controlled copy. Treat the backup repository as sensitive if its history may contain old secrets or internal code.
Encrypted archives and snapshots
Versioned backup software can capture changed files efficiently while retaining several recovery points. This matters when you discover a problem days later, after damaged or encrypted files have synchronized to a remote location. Use sensible retention: daily versions for recent work, weekly versions for a longer period, and occasional monthly snapshots for milestones.
Encrypt archives before they leave your device or are written to portable media. Choose modern, well-reviewed backup tools instead of creating your own encryption method. Use a long, unique passphrase and store it in a password manager or another recovery method that remains available if the primary computer is lost.
Encryption is only useful if you can recover the key. Do not keep the only passphrase in a text file beside the archive. For business or shared projects, document authorized recovery holders and follow the organization’s access policies.
Automate routine copies, but keep control points
Manual backups depend on memory, which tends to fail during deadlines. Automate routine tasks where possible: scheduled encrypted snapshots, regular remote pushes as part of your normal commit workflow, or a scheduled backup job for selected project directories.
Keep automation conservative. Back up defined directories rather than your entire home folder without review, exclude temporary build folders, and avoid scripts that silently upload sensitive files to an unapproved destination. On Linux and macOS, use restrictive permissions for local backup configuration files. On shared computers, use a separate account or protected storage area.
For repositories, make meaningful commits before major refactors, dependency upgrades, migrations, or experiments. A clean commit provides a useful recovery point. Before deleting a branch or rewriting history, confirm that another copy exists and that collaborators understand the change.
Verify backups by restoring them
A backup job can report success while saving incomplete data, corrupt archives, inaccessible permissions, or an encrypted file with an unavailable passphrase. Verification requires more than confirming that a file exists.
- Choose a recent backup copy and restore it to a temporary directory or separate machine.
- Confirm that expected files, hidden Git metadata, and documentation are present.
- Check the repository history with commands such as
git logand verify that important branches are available. - Install dependencies from the saved manifest, not copied caches.
- Build the project and run its test suite where practical.
- Confirm that setup instructions identify required secrets without exposing them.
Keep a short restore checklist in the repository. It should list the required runtime version, dependency command, database migration order, test command, and the approved location for secrets. That turns recovery into a repeatable process instead of an improvised search.
Set access and retention rules
Backups often outlive laptops, contracts, and team membership. Give access only to people who need it, remove access when roles change, and avoid sharing one backup password across a group. For shared repositories, decide who owns the backup destination and who can restore it during an incident.
Retention should match the value and sensitivity of the data. Keep release snapshots and tagged versions longer than experimental branches. Delete obsolete backups securely according to your policy, especially when they contain customer data or historical secrets. If you cannot confidently purge an old archive from every location, assume its contents may still be recoverable and rotate exposed credentials.
Run a simple restore drill each month: restore the latest backup into an empty folder, follow the documented setup command, and note any missing file or unclear instruction. Update the checklist immediately, while the project structure and recovery details are still fresh.
