12 Days of Gitmas: SSH vs. HTTPS

On the sixth day of Gitmas, my mentee asked of me...
what is SSH-ing?
how do I connect these,
what's this "GitHub" of which I've heard,
Git's ready - what then,
how do I get Git set up,
and could you explain Git, pretty please?

Welcome to Day 6 of the 12 Days of Gitmas, where we're discussing how to clone a repository that's not already on your computer, and what all the different options and terminology mean.

In the last post, we discussed connecting your GitHub repository to your local repository, and you may have noticed there was both an SSH and an HTTPS option for the link you use. What do these mean, and why would you use one versus the other?

HTTPS

HTTPS stands for HyperText Transfer Protocol Secure. (That "Secure" bit is why you may have noticed a lot of websites changing from http:// to https:// in the last few years.)

HTTPS is a way to securely send information to websites. This means that when you type in things like passwords, shipping addresses, or your credit card number, those are all encrypted when they're sent to the website.

For GitHub, using HTTPS to connect to your GitHub repository means that you'll have to enter your GitHub username and password into the command line every time you want to connect to GitHub (such as when you push a change).

SSH

SSH stands for Secure Shell.

This is a secure way to remotely log into a server.

When it comes to using GitHub, there ultimately isn't a huge difference between using HTTPS or SSH. However, when you use SSH, you'll have to generate something called keys to give yourself permission to connect to your GitHub repository - more setup up front, but you won't have to worry about entering your password over and over again.

To do this, you'll create a set of keys that lives on your computer. These keys are plain text files that you'll generate using the command line.

Your private key should never be shared with anybody - otherwise, they may be able to pretend that they're you and check things into GitHub with your account.

Your public key, on the other hand, can be shared. You'll add your public key to GitHub, which will allow GitHub to confirm that the person trying to change things in the repository is the same person that has access to the repository on GitHub. Each set of keys is unique, so if you want to push changes to the repository from another computer, you'll have to add the new computer's public key to your GitHub account as well.

If you want to generate keys to use with your GitHub account, GitHub has articles about using SSH and instructions for how to generate a new SSH key.

SVN?

You may also notice that when you click the "Clone or download" button to get the link for your repository, it also mentions SVN. SVN refers to Subversion, which is an alternative to Git. Since this series of articles is focusing on Git, I won't be going over Subversion, but just be aware that Subversion is another type of version control system.

Cloning a repository that you don't have locally

We've discussed how to connect your GitHub repository to your local repository, but what if you want to work on somebody else's repository - for example, if you're working on an open source project?

Go to their repository on GitHub, and just as we did when you were connecting your own repositories, click the green Clone or download button. Copy the link (either the HTTPS or SSH version, depending on your personal preferences and whether you've set up your keys or not yet), then go to the folder you have all your repositories in (NOT inside another project!) and type in your command line:

git clone [link]

After a moment, Git will create a new folder with the new repository name, and download all the project files into that project. Now you can make your own changes, and contribute to the project - I'll go over how to do that in upcoming posts!

You may also have heard of forking GitHub repositories. cloneing and forking are similar, in that they both allow you to work on the repository on your own. However, cloning just "checks out" the repository (like a library book) to your computer, and you can make changes locally (on your computer) and commit them back to the original remote (on GitHub) repository.

Forking a repository, on the other hand, creates your own version of that GitHub repository in your own GitHub account. This is a remote repository, meaning it is on GitHub. You can still make changes and check them back in, however the changes will go into your forked version of the repository, and not back into the original version.

If you want to contribute to someone else's project, then you should clone their repository using the command line. However, if you want to start your own project off of an existing open source project, you can fork it as a starting point for your own project. Once you have a fork of someone's project, you can clone your fork, so you can work on it locally.

(As for the other two buttons - "Star" means you're bookmarking the repository to save for later; "Watch/Unwatch" means you're choosing if you want to get notifications or not when something happens in that repository)

Now you know what SSH and HTTPS mean, and how to clone or fork someone else's project! In the next posts, I'll be going over how to contribute work to a project, what PRs are, and more!

If you have any questions about Git or requests for other topics you'd like to see me blog about, please leave a comment! And if you're enjoying this series, consider supporting me on Patreon, following me on Twitter or checking out my Twitch streams!