GitHub, and Publishing the Site

What GitHub adds on top of git.

Hosting, so your history survives your laptop.

A README rendered on the front page, which is the first thing anyone sees.

Issues, a list of what needs doing and what is broken.

Pull requests, a way to propose changes and discuss them before they land.

Pages, free hosting that serves a static site straight from your repository.

The README is the most important file in the repository. For a portfolio project it is the difference between a folder of code and something a stranger can understand. A good one answers, in this order:

What is this, in one sentence.

What does it look like, with a screenshot.

How do I run it locally.

How was it built, and what did you decide.

What is not finished yet.

That last one is a strength rather than an admission. It shows you know the difference between done and abandoned.

✦ GitHub Pages turns a repository into a website

For a static site, which is exactly what the HTML and CSS course produces, you can enable Pages in the repository settings and GitHub will serve it at a real URL, free and permanently. Push a change and the live site updates. That is what turns a project into something with a link you can put on an application.

SANKOFA SANDBOX

learner:~$

Try it → Init and commit, add a remote, and push. Then create a README with `echo '# My Portfolio' > README.md`, stage and commit it, and push again. Notice the second push sends only the new commit.

◈ Graded Task

Publish the repository. In the portfolio, initialize and commit everything, write a README.md whose first line is a level one heading naming the project, commit that too, then add a remote called origin pointing at a GitHub URL and push.

Checked against the filesystem you leave behind, not the commands you type, so any route that gets the job done counts. 5 visible and 2 hidden checks.

SANKOFA SANDBOX

learner:~$

Mark this lesson complete

Signed in, your progress follows you to every device.

Next: Practice Test →

← Back