Session 11: Deployment & Git Workflow

Test the things that only break in someone else's hands. Every link — a link that goes nowhere is the most common defect on a small site and takes two minutes to find. Every form, submitted with real data and with nonsense. Every page at every width you tested before. Images all loading, with no missing files showing broken icons.

Then the checks people forget. Console errors — open the developer tools on every page and confirm it is clean, because an error you have learned to ignore is still breaking something for a visitor. Loading on a slow connection — throttle the network in developer tools, because a page that loads instantly on your machine may take ten seconds on mobile data. Another browser and another device if you can, since a layout that works in one engine does not always work in another.

And the honest one: have someone else use it. Watch them, without explaining anything. Where they hesitate or click the wrong thing is where the design failed, and you cannot find those problems yourself because you already know how it works.

Code cleanup is not vanity — it is whether anyone, including you in three months, can work on the project again. Remove dead code: commented-out blocks you kept 'just in case', functions nothing calls, styles applied to elements that no longer exist. A reader cannot tell which commented code is a note and which is abandoned, so both become noise.

Then consistency: the same naming style throughout, the same indentation, the same way of doing the same thing. Inconsistent code forces a reader to re-learn your conventions in every file. A formatter removes this work entirely — configure one once and it enforces the style on save, so consistency costs nothing.

And remove anything secret before you publish. API keys, passwords, test credentials and personal data must not be in a public repository, and this is urgent rather than tidy: once pushed, a secret is in the history forever and must be treated as compromised and rotated. Keep secrets out of the repository from the start rather than removing them later.

The core loop is `add`, `commit`, `push`, and the discipline is small commits with messages explaining why. 'Add contact form validation' tells you something in six months; 'fixed stuff' does not. Commit after each working change rather than at the end of a session, because small commits are easy to understand, easy to review and easy to undo.

Then branches, which let you work on something without disturbing the working version. `git branch feature-name` creates one, `git checkout feature-name` moves you onto it, and commits there do not touch `main` until you merge. This matters even on a solo project: it means you can experiment without fear, and `main` always holds a version that works.

A pull request is a request to merge a branch, and it is where changes get reviewed before they land. On a team it is the normal way code moves forward; on a solo project it is still useful, because the diff view shows you exactly what you changed and the description forces you to say why. Then `git pull` brings others' changes down, and when two people edited the same lines you get a merge conflict — Git shows you both versions and you choose. Conflicts are normal, not a failure, and the fix is to read both sides and decide deliberately.

Deployment means putting your files somewhere a browser can reach them over the internet. For a static site — HTML, CSS and JavaScript, with no server code — that is genuinely all it is: your files, on a machine that is always on, served at an address. There is no compilation step and no server configuration to learn.

The modern way is a hosting platform connected to your GitHub repository. You authorise it, choose the repository, and it publishes the site and gives you a URL. Then every `git push` redeploys automatically, which means publishing is not a separate nervous step — you push, and a minute later the live site is updated. This removes the entire class of 'I forgot to upload the new file' problems.

The alternative is uploading files by FTP to a traditional host, which still exists and still works, but it is manual, error-prone and easy to get out of sync with what is in your repository. For a new project there is no reason to prefer it, and the automatic route means your live site always matches your repository.

For a static site, free tiers are genuinely adequate — platforms like GitHub Pages, Netlify and Vercel host static sites at no cost with HTTPS included, which was not true a few years ago and is worth knowing. Their free URLs are subdomains of theirs, which is fine for a portfolio project and worth replacing when the site represents a business.

A domain is the human-readable address — `yourname.com` — and it is bought from a registrar, usually for a modest annual fee in naira or dollars. Owning it means you can move hosts without changing your address, which matters: a site on a platform's subdomain is tied to that platform, and a business built on someone else's address is fragile.

Connecting them is a matter of DNS records — you tell the registrar where the site actually lives, usually by pointing the domain at the host or adding the records the host gives you. It takes minutes to configure and up to a day to propagate, which is why a newly connected domain sometimes appears not to work immediately. It is working; it has not spread yet.