FreeYour site host + gitAbout 40 min
Keep One Live Copy and Recent Backups
A deploy is the step that puts your files on the live site. Last deploy wins, so you must be sure you are editing the copy that is really live.
Why This Matters
A single deploy from a stale copy of a site once wiped a day of work. The old files went up and the new ones were gone. The fix is a habit of checking before you edit and before you push.
✓ How To Do It
- Name one place as the source of truth for each site. It can be a git repository or a single folder. Write the location in your site sheet.
- Before any edit, pull the latest copy. In git that is git pull. If you do not use git, download the live files and compare them with your folder.
- Check that your copy matches live. Open a changed page on the live site and in your folder and compare a recent edit. If they differ, stop and find out why.
- Make your edit on a branch or a dated copy, not on the only copy you have.
- Look at what changed before you push. In git, run git diff and read it. If it lists files you did not touch, stop.
- Deploy once per round, not after every small fix. Group changes and ship them together.
- After the deploy, open the live page and look for your change. Then push your work to the shared repository so the next person starts from it.
- Keep backups, but not forever. Keep the newest three. Old backups fill the disk and hide the useful ones.
- Test a restore once. Pick a backup, restore it to a scratch folder and open the site from it.
- Write down who may deploy. Two people deploying from two copies is how work disappears.
Done WhenThe site sheet names the live source, the last three backups are listed with dates, and a test restore opened correctly.
Reference List
Tips & Pitfalls
- Never force push to shared main. It can erase another person's work.
- If you build the site from a script, run it fresh and check the output, not the cache.
- If a deploy goes wrong, roll back first and investigate second.