GitHub stores a project in a repository. Each saved checkpoint is called a commit. For a small website, the point is not to become a programmer overnight: it is to avoid losing a working version when you make the next improvement.
1. Create one repository for the site
Keep the complete website folder in one repository: the homepage, style files, article folders and sitemap. Use a private repository if the site is not ready to be public. The repository is a history of your files, not another live copy of the website.
2. Make a checkpoint before a meaningful change
Before a new group of guides, a redesign or a deployment, save a commit with a plain description. Good examples are “Add Advanced website guides” or “Fix mobile navigation”. Avoid vague messages such as “changes” or “final final”.
3. Review what changed
Before saving a commit, look at the changed-file list and the comparison. Ask: did only the expected pages change? Did a link, contact form or sitemap disappear by accident? This quick review catches many mistakes.
4. Push the history to GitHub
A local commit is a checkpoint on your computer. Pushing sends that checked history to the repository online, giving you a separate copy if the computer is lost or the folder is overwritten.
5. Recover safely when something breaks
Do not panic and do not immediately delete files. Find the most recent known-good commit, compare it with the current version, then either restore the needed files or create a revert. For an already shared project, a revert is usually safer than rewriting history because it leaves a clear record of the correction.
6. Keep deployment separate from backup
GitHub is your change history; Netlify is where the finished site is published. The calm workflow is: make a change, test it locally, commit it, push it, deploy it, then check the public site.