Now, we’ve said that GitHub (which is a proprietary web front-end to Git run and owned by Microsoft) is not Git, and it’s true. It’s also true that you never even need to touch GitHub in order to use Git.
That said, it’s really common for people to use GitHub, so we’ll get it set up in this chapter.
Here we’ll make a new GitHub account and see how authentication works. This involves some one-time setup.
If you already have a GitHub account, you can skip that section.
If you already have authentication set up with GitHub CLI or with SSH keys, you can skip that section, as well.
If you don’t need to use GitHub, you can skip the entire chapter!
Head on over to GitHub8 and click Sign Up. Follow those instructions.
Eventually you’ll end up on your home screen dashboard.
This will make a repository on GitHub that you own. It does not make a local repository—you’ll have to clone the repo for that, something we’ll do later.
In GitHub, there’s a green New button on the left of the dashboard.
Also, there’s a + pulldown on the upper right center that has a “New Repository” option. Click one of those.
On the subsequent page:
Enter a “Repository name”, which can be anything as long as you don’t already have a repo by that name. Let’s use test-repo for this example.
Check the “Add a README file” checkbox.
(In the future, you might already have a local repo you’re going to push to this new repo. If that’s the case, do not check this box or it’ll prevent the push from happening.)
Click Create repository at the bottom.
And there you have it.
Before we get to cloning, let’s talk authentication. In the previous part of the intro, we saw that username/password logins were disabled, so we have to do something different.
There are a few options:
GitHub CLI is likely easier. SSH keys are geektacular. I only recently learned that you could authentication with personal access tokens, so I can’t really speak to them much.
Personally, I use SSH keys. But other people… don’t. It’s up to you.
If you already have authentication working with GitHub, skip these sections.
This is a command line interface to GitHub. It does a number of things, but one of them is providing an authentication helper so you can do things like actually push to a remote repo.
Visit the GitHub CLI page9 and follow the installation instructions. If you’re using WSL, Linux, or another Unix variant, see their installation instructions10 for other platforms.
Once you have it installed, you should be able to run ‘gh –version’ and see some version information, e.g.:
$ gh --version
gh version 2.42.1 (2024-01-15)
https://github.com/cli/cli/releases/tag/v2.42.1Then you’ll want to run the following two commands:
$ gh auth setup-git
$ gh auth loginThe first is one-time only.
The second command will take you through the login process. You’ll have to do this again if you log out.
When choosing the authentication type between SSH and HTTPS, I recommend SSH. You’ll need to remember your choice when you go to clone a repo later.
If you don’t want to install and use GitHub CLI, you can take this approach instead. This is more involved, but has more geek cred. This is what I use.
If you already have an SSH keypair, you can skip the key generation step. You’d know you had one if you ran ls ~/.ssh and you saw a file like id_rsa.pub or id_ed25519.pub.
To make a new keypair, run the following command:
$ ssh-keygen -t ed25519 -C youremail@example.com(The -C sets a “comment” in the key. It can be anything, but an email address is common.)
This results in a lot of prompts, but you can just hit ENTER for all of them.
Best practice is to use a password to access this key, otherwise anyone with access to the private key can impersonate you and access your GitHub account, and any other account you have set up to use that key. But it’s a pain to type the password every time you want to use the key (which is any time you do anything with GitHub from the command line), so people use a key agent which remembers the password for a while.
If you don’t have a password on your key, you’re relying on the fact that no one can get a copy of the private portion of your key that’s stored on your computer. If you’re confident that your computer is secure, then you don’t need a password on the key. Do you feel lucky?
Setting up the key agent is outside the scope of this document, and the author is unsure of how it even works in WSL. GitHub has documentation on the matter11.
For this demo, we’ll just leave the password blank. All of this can be redone with a new key with a password if you choose to do that later.
Anyway, just hitting ENTER for all the prompts gets you something like this:
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_ed25519
Your public key has been saved in id_ed25519.pub
The key fingerprint is:
SHA256:/lrT43BQBRPJpUXxpTBFInhdtZSQjQwxU4USwt5c0Lw user@locahost
The key's randomart image is:
+--[ED25519 256]--+
| .o.X^%^=+|
| ..oo*^.=o|
| ..o = o..|
| . + E |
| S . |
| . o |
| . + + |
| o = . |
| ... . |
+----[SHA256]-----+If you chose any file name other than the default for your key, you’ll have to do some additional configuration to get it to work with GitHub12.
What’s that randomart thing with all the weird characters? It’s a visual representation of that key. There are ways to configure SSH so that you see the randomart every time you log in. And the idea is that if one day you see it looks different, something could be amiss security-wise. I doubt most people every look at it again once it’s been generated, though.
Now if you type ls ~/.ssh you should see something like this:
id_ed25519 id_ed25519.pubThe first file is your private key. This is never to be shared with anyone. You have no reason to even copy it.
The second file is your public key. This can be freely shared with anyone, and we’re going to share it with GitHub in a second so that you can log in with it.
If you have trouble in the following subsections, try running these two commands:
$ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/*You only have to do that once, but SSH can be a bit picky if the file permissions on those files aren’t locked down.
Now in order to make this work, you have to tell GitHub what your public key is.
First, get a copy of your public key in the clipboard. Be sure you’re getting the file with the .pub extension!
$ cat ~/.ssh/id_ed25519.pubYou should see something like this:
ssh-ed25519 AAAC3N[a bunch of letters]V+znpoO youremail@example.comCopy the entire thing into the clipboard so you can paste it later.
Now go to GitHub, and click on your icon in the upper right.
Choose “Settings”.
Then on the left, choose “SSH and GPG keys”.
Click “New SSH Key”.
For the title, enter something identifying, like, “My laptop key”.
Key type is “Authentication Key”.
Then paste your key into the “Key” field.
And click “Add SSH key”.
We’ll be using SSH to clone URLs later. Remember that.
Remember last chapter when we tried to clone an HTTPS repo URL on the command line and it prompted for a username and password that didn’t work?
Well, we get to actually make new passwords that will work in that case. They’re called personal access tokens.
GitHub has a lot of documentation on this13 but the gist of it is that you’re going to create a token that represents some kind of access, e.g. “ability to read and write my repos”, and you’re going to use that in lieu of the password on the command line.
So that last failed example would look like this:
Username for 'https://github.com': [MY USERNAME]
Password for 'https://beejjorgensen@github.com': [MY TOKEN]In other words:
Your computer might automatically save those credentials so you don’t have to enter them every time. Or it might not.
One of the main things personal access tokens can give you is fine-grained control over access. You can limit access to read-only, or just to certain repos, and so on.
Additionally, you can use GitHub CLI authentication with a token as well. You just have to feed it in there on standard input. Let’s say you have your token in a file called mytoken.txt. You can authenticate with GitHub CLI like so:
$ gh auth login --with-token < mytoken.txtLike with SSH keys, if you lose a laptop that uses a particular access token, you can simply invalidate that token through GitHub’s UI so that mean people can’t use it.
We need to figure out the URL to the repo so we can clone it.
If you click on your icon in the upper right, then “My Repositories”, you should see a page with all your repos. At this point, it might just be your test-repo repo. Click on the name.
And you should then be on the repo page. You can browse the files here, among other things, but really we want to get the clone URL.
Click the big green “Code” button.
What you do next depends on if you’re using GitHub CLI or SSH keys.
You have two options.
Option 1: Earlier when we authenticated with gh auth login I said to remember if you chose HTTPS or SSH. Depending on which you chose, you should choose that tab on this window.
Copy the URL.
Go to the command line and run git clone [URL] where [URL] is what you copied. So it’ll be this for HTTPS:
$ git clone https://github.com/user/test-repo.gitor this for SSH:
$ git clone git@github.com:user/test-repo.gitOption 2: Choose the “GitHub CLI” tab. Run the command as they have it, which will be something like:
$ gh repo clone user/test-repoIf you set up an SSH key earlier, you can use this method.
After hitting the green “Code” button, make sure the “SSH” tab is selected.
Copy that URL.
Go to the command line and run git clone [URL] where [URL] is what you copied. So it’ll be something like this:
$ git clone git@github.com:user/test-repo.gitNow that you’ve cloned the repo, you should be able to cd into that directory, edit a file, git add it to the stage, then git commit -m message to make a commit…
And then git push to push it back to the clone on GitHub!
And after that if you go to the repo page on GitHub and hit reload, you should be able to see your changes there!
And now we’re back to that standard common flow:
There are two main techniques for this:
We’ll talk about the first one in the future.
For now, the easiest way to add collaborators is to just add them to your repo.
On the repo page on GitHub, choose “Settings”, then “Collaborators” on the left.
After authenticating, you can click “Add people”. Enter the username of the person you want to collaborate with.
They’ll have to accept the invitation from their GitHub inbox, but then they’ll have access to the repo.
Be sure to only do this with people you trust!