A few years ago, I had an honestly embarrassing first encounter with GitHub. I didn’t work in any kind of technical field, had never heard of Git before, had never used my command line, and just wanted to host a website. While GitHub was absolutely not the best choice for this, it’s what I bumbled my way into and it eventually worked.

That “eventually,” however, meant I spent a ridiculous amount of time (think easily a dozen hours - like I said, it was embarrassing) trying to figure out what to make of this GitHub thing, far longer than it took me to actually write out and test the code for my website. It turned GitHub into this mysterious, mythological beast that I’m still vaguely intimidated by, even as I get more comfortable in its presence.

For those of you out there who don’t understand GitHub, who are intimidated by GitHub, who don’t entirely know why or when or how people actually use GitHub, this guide is for you. I’m no expert, but I’ve been in your shoes, and think we can tame this beast (at least a little) together.

Git And GitHub Are Not The Same

One confusion I had early on was that I’d see references to Git and references to GitHub and it didn’t even cross my mind that these were different beasts.

The short of it: Git is your local version control, a tool you can use to create and keep track of versions of your code so that you can reference or revert back to previous iterations. GitHub is a way of hosting Git repositories (their fancy word for collections of versions and connected files), so that you can share and collaborate your code. You can do all of your local version control on your own computer using Git, without ever connecting to the internet. But, GitHub allows you to move those versions of your code to the cloud if you so choose, and has developed some tricks for working with others on the same projects.

When you first start out and you create a repository (the folder for all of your files you want to keep together and to maybe someday share) you can do that locally with Git or online on your GitHub account - whatever works for you!

I'll give you two guides to follow when you do this: If you start a repository locally, you need to tell GitHub that this exists and give it permission to make copies that for it to keep online. If you start a repository in GitHub, you need to ‘clone’ it to copy it onto your local machine to work on it.

How do you know which of the above guides to follow? If you’ve already written your code, I’d go with the first option. If you’re just starting out, I think it’s a little easier to make the repository on GitHub and then ‘clone’ it to work locally.

There Are More Steps In Git Than You Think You Need

First, let’s look at the part of Git that’s useful when you’re just starting out with GitHub. Why do I need to ‘add’, then ‘commit’, then ‘push’ my code? When working on smaller projects, all of these fundamental steps can seem redundant, and the terms aren’t necessarily intuitive, so let’s break down each one.

I think of working with Git as working with a play, so bear with me as I try to make this metaphor work.

When you ‘add’ something in Git, you’re basically prepping an actor backstage to go out onto the main stage, but the actor is still behind the curtain. You can prepare everything for the stage in one fell swoop, but maybe you don’t want everything to go on stage at once - some of the actors aren’t in costume or ready yet! The intention of ‘add’ is to tell Git which files are actually going to go on stage during this scene, while the other actors aren’t ready just yet and will come into the action when it makes more sense in later scenes.

When you ‘commit’ something in Git, you’re actually moving those prepared actors (files) onto the stage. This should be done with some kind of introduction, a line spoken as the actor comes onto the stage so the audience can understand why the actor is there - this is conveyed with good ‘commit’ messages!

Committing something does NOT actually put the stage in front of an audience, however. When you ‘push’ something in Git, you’re moving the scene you’ve written, with all the proper actors on the stage, into the actual play. If you ‘push’ to your GitHub, this means not only adding the scene to the play but also putting that play, with the new scene, in front of an audience! Now, others can watch your scene unfold by visiting your GitHub repository.

If you don’t know whether your actors are behind the curtain before the scene, or on the stage during the scene, or whether the scene has been added to the play (aka if you don’t know whether you need to ‘add’, or ‘commit’ or ‘push’) you can check your Git ‘status’. In the command line of the most basic terminals, it will tell you exactly what has been added to your repository, what has been committed to your repository, and what the status of your local work is compared to the original you began working with (probably in color, even!). Check out this tutorial on Git basics to go into more detail and to get into the nitty gritty of how to run these Git commands.

The Purpose Of GitHub Is Collaboration

If you aren’t working on a team, and want to hoard your code and not share it with anyone ever, you might not need GitHub. But it’s much more likely that you’re either going to be working with other people or will want to share your work with others, so getting a little comfortable with GitHub is valuable.

This focus on collaboration is why you can ‘branch' your code, which is a fancy way of saying that your code is going in a new direction from here on out. You can ‘merge’ those branches later on, if your main trunk of code and your side-branch end up going in the same direction again. New metaphor, I know, but the tree metaphor was clearly what Git and GitHub had in mind and it’s the easiest way for most to conceptualize this.

What about pulling, and why is a ‘pull’ different from a ‘pull request’? A ‘pull’ is a Git command to bring in changes that have been made on a different branch. A ‘pull’ command is the combination of a ‘fetch’ command and a ‘merge’ command - you’re going to a remote piece of code (‘fetch’) and then smushing it together with your current piece of code (‘merge’).

On the other hand, a ‘pull request’ is a GitHub action which allows you to request that a branch (or other connected piece of code) get added into the main trunk of the tree - you’re grafting the pulled code onto the main trunk, to stick with our new tree metaphor.

All of this collaboration stuff - branches, merges, pulls and pull requests - are designed to make sure that every member of a team can work independently, but can combine their work without overriding each other. This is why merge conflicts are a necessary evil. I won't go into them here, because other people have way more experience in handling merge conflicts than I do, but just know that they happen, it's okay, you'll get through this. And remember, GitHub is trying to help, even if it's annoying sometimes.

A Tamer Beast

This only covers the very basics, since Git and GitHub are vital tools that take time to master. But I feel more comfortable in the presence of GitHub, even if it still surprises me and I still don’t completely trust that it won’t rear up and attack me. I hope you do too! Check out the many links above, as they all dive way deeper into the details and are great resources.

Was this helpful to conceptualize how and why you use these tools? Any fun ways you think about GitHub (or Git) - any other metaphors? Let me know!

Cover image sourced from Diana Neculai with FreeCodeCamp, the three GIFs are from GIPHY.