Why developers use Git
Git records project history. It lets you save checkpoints, compare changes, recover older versions, and work on features safely.
Repositories
A repository is a project tracked by Git. It includes your files and a hidden .git directory that stores history.
Basic workflow
The normal workflow is status, add, commit, and push. Each commit should represent a meaningful checkpoint. Review git status and git diff before committing so unrelated edits, temporary files, and accidental deletions do not enter the project history.
Branches
Branches let you work on a feature without damaging the stable version of your site. Give the branch a descriptive name such as feature/contact-form or fix/mobile-navigation. Keep changes focused so the branch remains easy to review.
Deployment
Static sites can be deployed to Firebase Hosting, GitHub Pages, Netlify, Vercel, Cloudflare Pages, and similar services. Deployment is not the final step: open the live URL and verify routes, asset paths, forms, responsive layouts, and console output. Hosting behaviour can differ from opening local files directly.
Protect secrets and recover safely
Never commit private keys, passwords, access tokens, or privileged configuration to a public repository. Use a .gitignore file for local-only files. If a release introduces a serious issue, return to a known-good version or redeploy the previous working release rather than editing production blindly.
Example code
git init
git status
git add .
git commit -m "Create homepage"
git checkout -b feature/course-cards
git push origin feature/course-cardsApplied example: verify before publishing
This lightweight release routine records the exact version being deployed and checks the live result.
git status
git diff
git add .
git commit -m "Add validated contact form"
git push origin main
# After deployment:
# 1. Open the live homepage
# 2. Test navigation and forms
# 3. Check narrow and wide layouts
# 4. Confirm the browser console is cleanGuided example: how to approach this lesson
Use these steps as a practical build process. The goal is not just to read the concept, but to know exactly how to apply it in your own page.
Step 1: Save meaningful checkpoints
Commit after completing a logical piece of work, such as building the header or finishing a lesson page.
Step 2: Use clear messages
A commit message should explain what changed. This makes the project history useful.
Step 3: Test before publishing
Open the site locally, check links, check responsive layouts, and fix console errors before deployment.
More examples
Compare these examples carefully. The improved version shows the kind of code pattern you should aim for when building your own project.
Weak commits
git commit -m "stuff"
git commit -m "changes"
git commit -m "final final" These messages do not explain what happened.
Better commits
git commit -m "Build responsive homepage hero"
git commit -m "Add lesson learning panels"
git commit -m "Fix mobile navigation menu" These messages make the project history easier to understand.
Before moving on
Use this checklist to make sure you understand the lesson well enough to apply it without copying blindly.
- Are commits small and meaningful?
- Do commit messages describe the work?
- Are links and file paths correct before deployment?
- Have you tested the deployed version?
Common mistakes to avoid
- Committing huge unrelated changes.
- Using unclear commit messages.
- Publishing with broken links.
- Putting private secrets in public repositories.
Practice task
Track your homepage project with Git and prepare a repeatable release process.
Required outcome
- Initialise a repository and make at least three focused commits with descriptive messages.
- Create a feature branch, make one improvement, and review the diff before merging it.
- Add a
.gitignorefile for any local-only files in your project. - Deploy the site, open the live URL, and complete a written post-deployment checklist.
Stretch goal: Record how you would restore the previous working release if the new deployment failed.