What GitHub is

A place to keep files along with their whole history, and to show them to people if you choose. Each project lives in a repository: a folder plus every change ever saved to it. Educators use it for lesson sites, shared materials, and small tools. The history is the point: every saved change is kept, with who made it and when, so a saved change is never lost by accident. GitHub is one of several services that host Git repositories; the habits in this guide work on the others too.

Why a personal account

The best way to learn this is to work on your own ideas and problems: a lesson you'd like to rebuild, a small tool you wish existed, a list you want to keep, a question you want to try out. A personal account is a place to explore, make mistakes, and start over, and the history keeps a record of what you tried.

If your district doesn't allow GitHub

Some districts limit GitHub or Codespaces on their devices, networks, or accounts, for reasons you may not see from where you sit. That's their call, and it's an answer, not an obstacle. What you're learning here is version control: keeping a history of changes, saying why you made each one, and comparing versions. Git, the free tool underneath, isn't tied to GitHub, and Google Docs and Microsoft 365 both keep version histories you can practice the same thinking on. The ideas in this guide go with you either way.

What this guide asks of you

A browser and some curiosity. Chapter 4 gets you working in Codespaces and introduces Claude Code, Codex, and Gemini CLI. Chapter 5 gives you a visible milestone: a web address of your own. The lasting skill is making, checking, saving, and returning to useful work. The end of any chapter is a fine place to stop.

Worth knowing, once

Steps

1. 01

   Check what your district allows

   Your staff handbook, or district officials, will have the acceptable-use policy. Read what it says about devices, networks, and accounts. If GitHub isn't open to you, you can still read on for the ideas, and ask what is.

   Not yet
2. 02

   Pick the email you'll sign up with

   One you control and will still have in ten years. GitHub uses it to reach you and to help you recover the account.

   Not yet
3. 03

   Decide what you'll practice on

   Something with no real people in it: a lesson page about rivers, a list of your favorite poems, a made-up class called Room 12.

   Not yet

Steps

1. 01

   Sign up at github.com/signup

   Use the email you chose. Then verify it: until you do, you can't create a repository.

   Not yet
2. 02

   Turn on two-factor authentication

   Settings › Password and authentication. GitHub suggests an authenticator app first, with a passkey or security key as backup. It asks everyone who contributes code to turn this on, so do it on day one.

   Not yet
3. 03

   Save your 16 recovery codes somewhere you'll find them

   A password manager, or a printed copy at home. This is how accounts get lost: if the phone and the codes are both gone, GitHub Support can't restore the account.

   Not yet

Steps, continued

4. 04

   Keep your email private

   Settings › Emails: tick Keep my email addresses private and Block command line pushes that expose my email. From then on your changes carry an address like ID+yourname@users.noreply.github.com.

   Not yet
5. 05

   Optional: add your school email

   Only if you plan to apply for GitHub Education (next page), which looks for a school address. Settings › Emails › Add, then verify it. Leave the “Primary email address” dropdown as it is, so the account doesn't depend on any one job.

   Not yet

GitHub Education for teachers

Optional. GitHub asks that you be an educator with a verifiable school-issued email, and that you upload something proving your school affiliation, such as a faculty ID or an employment letter. You apply from your personal account: Settings › Education benefits › Start an application. People who have applied report that the form may ask your browser for your location; GitHub's own pages don't mention it. GitHub's wording is about accredited institutions and never names K-12 either way, so apply with your school email and see. Describe your role as it is; whether it qualifies is GitHub's call.

What a verified teacher gets: a free Copilot Pro subscription, a free Team plan for a shared group account (GitHub calls it an organization), GitHub Classroom, and a teacher discussion space.

Copilot, in a paragraph

Copilot is GitHub's AI assistant inside the editor. It suggests code and answers questions about the file you're in. Copilot Pro is normally $10 a month; verified teachers get it free, and GitHub re-checks eligibility every month. After your Education application is approved: profile picture › Copilot settings › Get access. Whether to use it is your call; it's one tool among several, not a requirement for anything in this guide. It's a suggestion machine, not a checker: what it writes is yours to read before you keep it. What you type into it leaves your computer, so the rule for repositories applies here too: nothing with real students or staff in it.

Free, and when you'd need Pro

Checked against GitHub's plans page on the date in Resources.

What a teacher might want from Pro is a public site from a private repository; chapter 5 explains why that matters less than it sounds.

Repository

A project's folder, with every file's history kept alongside. “Repo” for short.

Commit

One saved change, with a short note about what you did and why. Each gets a permanent ID.

Push

Sending your commits from where you made them up to GitHub. In a codespace this is the Sync Changes button.

Branch

A parallel version of the repository where you can try something without touching the main one. The main one is usually called main.

Fork

Your own copy of someone else's repository, on your account. You can change it freely; the original doesn't change. Forking a public repository is allowed on GitHub; reusing its contents elsewhere depends on its license (chapter 6).

Clone

A copy of a repository on a computer, or the act of making one. A codespace clones your repository to get started.

Pull request

A proposed change, shown as a comparison, that someone can review and accept. How people suggest fixes to each other's work.

README

A text file that says what the repository is. GitHub shows it on the repository's front page.

.gitignore

A list of files Git should leave out of commits. Where you name anything that must never be pushed.

Markdown

Plain text with light formatting marks: # for a heading, * for a list. READMEs are written in it.

Issue

A note attached to a repository: a task, a question, a bug. Anyone with a GitHub account can open one on a public repository that has issues turned on.

You'll learn these by doing. Don't stop for them.

Merge, remote, origin, HEAD, staging, rebase, Actions, workflow, token, SSH. Each will make sense the first time it's in front of you, and not before. If one blocks you, search “github docs” plus the word.

Steps

1. 01

   Read the eleven once

   Then come back when a word stops you. That's what this chapter is for.

   Not yet

A codespace opens with a copy of one repository and a web version of Visual Studio Code, a widely used editor, already set up. You edit, save, commit, and push from inside the tab. Close the tab and the codespace waits for you; open it again and your files are where you left them.

What you get

Checked against GitHub's billing and Codespaces docs on the dates in Resources.

Steps

1. 01

   Make a repository to practice in

   github.com › the plus sign › New repository. Name it room-12, tick “Add a README file,” and make it public: chapter 5 needs that on the free plan, and this practice repository holds nothing that matters. That README is your first file.

   Not yet
2. 02

   Open a codespace on it

   Code›Codespaces›Create codespace on main

   A line at the bottom of that dialog says who pays. For your own repository on the free plan, it's your included hours. Wait a minute while it builds.

   Not yet
3. 03

   Find the editor, the terminal, and Source Control

   The editor is the big middle. The file list is on the left, and the icon under it with the branching lines is Source Control. The terminal, a text box that takes typed commands, is along the bottom; if it's hidden, the three-line menu icon at the top left has Terminal › New Terminal. You'll mostly use the editor.

   Not yet

Steps, continued

1. 04

   Change a file, commit, and push

   Open README.md, add a line, save. In Source Control, type a short message in the box (“Add a welcome line”), click Commit, then Sync Changes. Read the changed-file list before staging: include only files you meant to change. If Sync asks to pull and push, say OK. Back on github.com, reload the repository: your line is there, and the commit carries your noreply address.

   Not yet
2. 05

   Stop the codespace when you're done for the day

   github.com/codespaces lists yours. The three-dot menu beside it has Stop codespace, and Delete when you no longer want it. Stopping saves your hours; it would stop itself after 30 idle minutes anyway.

   Not yet

AI help, when you want it

Describe a change. See it in your files. Decide what stays.

An assistant connected to your codespace can explain a file, suggest a revision, and make an edit for you to inspect. For a teacher, that might mean clearer activity instructions, three discussion questions, or a small classroom tool.

These are three options, not three things to install. Choose a service you already use and are allowed to connect. GitHub sign-in does not include access to these services.

Use invented practice material. Connected assistants may send prompts and project content to their providers. Keep approval prompts on and review changes. If an approved setup needs an API key, use a Codespaces secret; keep it out of files and chat.

Make one useful change

A lesson note you can improve, save, and return to.

Use your practice repository with invented material. You can do every step yourself in the editor. If an assistant is already connected, the optional prompts below let you try the same change with help.

1. 01

   Make a starting point you can return to

   Create lesson.md in the file list. Type a heading, # River questions, and a sentence: “How does a river change the land?” Save, commit, and sync as in the previous steps. The .md ending means a plain-text document with simple formatting.

2. 02

   Add something useful

   Keep your original question. Add these three questions underneath, or write three of your own. Save the file, then review the difference before committing.

Keep it, change it, or undo it

Open Source Control and select lesson.md. Read the difference between the saved version and the new one. Check that your original question remains, there are three new questions, and no unrelated file changed. You still decide whether the questions make sense for your teaching.

If the result helps, commit it with a message such as “Add river discussion questions,” then sync. If it misses the point, describe one correction. You do not need to accept every suggestion.

git diff -- lesson.md

git restore --source=HEAD -- lesson.md

A workspace you can come back to

Leave a sentence in your README about what you want to try next, commit and sync it, then stop the codespace. Next time, reopen it and read that note before starting an assistant. Your project's files and history are the continuity; the chat is help along the way.

What it needs

• A public repository, on the free plan. (Pro can publish from a private one.)
• An entry file at the top: index.html, index.md, or README.md.
• Pages turned on: Settings › Pages › Deploy from a branch.

Two kinds of address. A repository named yourname.github.io becomes https://yourname.github.io. Any other repository becomes https://yourname.github.io/its-name. Start with the second kind.

Worth knowing, once

Steps

1. 01

   Add an index.html to your practice repository

   In the codespace, or with Add file › Create new file on github.com. Name it index.html and paste this in, then change the words. This is HTML, the plain text a web page is made of; the words between the angle-bracket tags are yours. (A fuller version with notes is in the Library.)

   <!doctype html>
   <html lang="en">
   <head><meta charset="utf-8"><title>Room 12</title></head>
   <body>
     <h1>Room 12 reads about rivers</h1>
     <p>This week: where the Mississippi starts.</p>
   </body>
   </html>

   Not yet
2. 02

   Commit and push it

   Source Control › message › Commit › Sync Changes, as in chapter 4. Or, on github.com, Commit changes.

   Not yet

Steps, continued

1. 03

   Turn Pages on

   Settings›Pages›Deploy from a branch›main›Save

   Not yet
2. 04

   Wait, then open the address

   Up to 10 minutes the first time, usually less. The address appears on the same Settings › Pages screen. Open it on a phone, too: if it loads there, it's on the open internet.

   Not yet

No license means all rights reserved

With no license file, default copyright applies: you keep every right, and nobody may legally copy, share, or build on your work, even though GitHub's terms let them look and fork. If you want colleagues to be able to use a lesson, that's the opposite of what you mean, and a license fixes it in a minute. Keeping all rights is a fair choice too; the point is that it should be a choice.

Both Creative Commons licenses are in GitHub's own license picker, so adding one takes the same minute as MIT. A repository with code and lesson text can carry two licenses: MIT in LICENSE, and a line in the README saying the words are CC BY 4.0. The Library has that notice ready to paste. This guide does the same with CC BY-NC 4.0 for its words (no commercial use); that license isn't in GitHub's picker, so the README and the footer of every page name it.

A license only covers what's yours to license, which may not include work made for your job, a publisher's materials, or student work. If you aren't sure, ask first.

Steps

1. 01

   Decide what's public while the repository is still small

   Settings › General › Danger Zone › Change visibility. You can change it later, but the whole history changes with it.

   Not yet
2. 02

   Add a license

   Add file›Create new file›LICENSE›Choose a license template

   Pick one, fill in the year and your name, Review and submit, Commit changes. The repository's front page now shows the license beside the description.

   Not yet

What clasp gives you

Apps Script's browser editor keeps versions, but not a Git history you can share or keep somewhere of your own. clasp is Google's tool for the terminal you met in chapter 4: it copies a script project to ordinary files and back. Put those files in a repository and you get everything this guide has been about: a history of every change, a place to describe the project, pull requests from a colleague, and a codespace to edit it in from any browser.

Steps

1. 01

   Turn on the Apps Script API for the Google account you're practicing with

   Open script.google.com/home/usersettings, signed in as that account, and switch it on.

   Not yet
2. 02

   Install clasp in a codespace

   In the terminal of a codespace on your own repository. The default codespace already has Node, the program clasp runs on; npm is Node's installer, and -g means for the whole codespace.

   npm install -g @google/clasp

   Or let the codespace install it as it builds: the Library guide explains every line before you copy it.

   Not yet
3. 03

   Log in without a local browser

   A codespace can't open a window on your screen, so --no-localhost prints a link instead. Open it, sign in as that same account, and paste the code back into the terminal.

   clasp login --no-localhost

   Not yet

Steps, continued

1. 04

   Bring a script project down, change it, push it back

   The script ID is in the project's settings in the Apps Script editor. Replace <script-id>, brackets included, with it; --rootDir src gives the script's files their own folder. Before you commit, read every file once: scripts often carry a spreadsheet ID or an email address, and a public repository shows them to everyone. Check, too, that your .gitignore names .clasprc.json; the Library guide has one, explained line by line. And clasp push replaces the whole online copy with yours, so pull before you push if anyone else edits the project.

   clasp clone-script <script-id> --rootDir src
   clasp pull
   clasp push

   Not yet
2. 05

   Log out before you leave

   This deletes the saved sign-in from the codespace. Do it every time you finish.

   clasp logout

   Not yet