Recall from lesson 1-1 the distinction that matters here: Git is the version control tool on your computer, and GitHub is a website that hosts Git repositories online.
They are separate things that work together. Git existed before GitHub and works perfectly without it, which is why everything in units 1 through 6 was pure Git, entirely on one machine.
This unit finally connects that machine to the outside world, which is where the second half of the word GitHub starts to matter.
Remotes
A remote is another copy of your repository living somewhere else, almost always on a server such as GitHub. The server copy is the meeting point: you send your commits up to it, teammates send theirs, everyone downloads everyone else's.
Getting a project from GitHub takes one command. Every repository page on GitHub shows a URL, and:
$ git clone https://github.com/octocat/recipe-book.git Cloning into 'recipe-book'... remote: Enumerating objects: 128, done. Receiving objects: 100% (128/128), done.
git clone creates a folder, downloads the repository into it, and wires the folder back to the URL it came from. And because a Git repository is its history, you receive every commit ever made, the full chain from lesson 1-2, not just the latest files. You can run git log, git diff, and git switch on an airplane, the whole database is local.
origin, the default nickname
Typing the full URL constantly would be miserable, so Git gives remotes short names. When you clone, the source URL is automatically nicknamed origin:
$ git remote -v origin https://github.com/octocat/recipe-book.git (fetch) origin https://github.com/octocat/recipe-book.git (push)
That's all origin is: a bookmark meaning "the server this project came from." There is nothing magical about the name, but since every clone gets it automatically, it's the word you'll see in every push and pull for the rest of your career.
Starting a project the other direction (local first) works too: create an empty repository on GitHub, then connect it yourself with git remote add origin <url>.
Proving who you are
Reading a public repository needs no account at all. git clone on a public URL just works, which is why you could grab any open-source project this afternoon without signing up for anything.
Writing is different. git push, coming in the next lesson, changes the project on the server, so the server has to verify you are allowed to. Without that check, anyone could rewrite anyone's code.
GitHub accepts two forms of identification.
- HTTPS with a personal access token. GitHub stopped accepting account passwords for Git operations in 2021, because passwords leak and cannot be scoped to a limited purpose. You generate a token in GitHub's settings, which is a long random string acting as a restricted password, and paste it when Git prompts. A credential helper, enabled by default on macOS and Windows, remembers it after the first time.
- SSH keys. You generate a key pair once with
ssh-keygen, upload the public half to GitHub, and keep the private half on your machine. Clones then use thegit@github.com:...URL form, and pushes authenticate silently with no prompt.
Both are perfectly fine. SSH is the usual choice on a computer you own, because it never asks again, while tokens are common on shared or temporary machines where leaving a key behind is undesirable.
Either way this is a one-time setup toll that everyone pays. Budget ten minutes with GitHub's current documentation the first time a push asks you to prove yourself, since the exact screens change more often than the concepts do.
After git clone finishes, you have the complete repository: all the files, the full commit history, and a remote named origin pointing back at the source.
Clone copies the entire repository rather than a working copy of the latest version. Every snapshot ever committed comes down, and the source URL is bookmarked as origin so later commands do not need it spelled out.
That completeness is why your local commands keep working with no network at all. git log, git diff, and git switch read the database in .git, which is now sitting on your disk in full, so history browsing on an airplane is entirely normal.
Cloning a public repository needs no account while pushing demands authentication because reading public code is open to everyone, but pushing writes to the project on the server, so the server must verify you have permission.
Public repositories are public to read, which is the entire point of open source. Nothing needs protecting on that side, since the code is already published.
Writing is the operation that changes the project for everyone who clones or pulls afterwards. That is why the server checks identity, through a personal access token over HTTPS or an SSH key, before it will accept pushed commits. The asymmetry is not Git being inconsistent, it is the difference between looking at something and altering it.
The command is git clone <url>.
It creates a local folder containing the full repository, history included, and sets up origin pointing at the URL you gave it, so pushes and pulls later need no address.
This is the standard first step whenever you join an existing project, and in practice it is how most working days on a new codebase begin. The only decision it involves is which URL form to use, HTTPS or SSH, which follows from how you chose to authenticate.