GitHub For Dummies

Everything you need to know about getting started with GitHub, and why you should’ve done it sooner.

It wasn’t until I had been coding for seven years that I finally learned how to use GitHub. I know, I know — *gasp*.

During my Developer Relations internship at Google, I quickly found that I needed to start understanding GitHub fast, as the majority of my team’s code development, sharing, & code reviews were occurring on the platform. Nine weeks and many Google search queries later, I finally understand how to use GitHub as a tool, even if just at the ‘beginner’ level. Dare I go so far as to call myself a tech bro?

GitHub, self-described as ‘the world’s leading software development platform’, allows developers to publish their code, share their code, and socially-network with regards to their code. Nerdy! GitHub also allows you to store and view every draft of a code file you have made, ever, easily allowing for you to not only view progress, but revert to a file’s earlier versions if (when) mistakes occur. Additionally, while one can manually add, remove, and alter files directly from GitHub.com, one can also adapt the more tech-savvy version: dealing with GitHub entirely from the command line.

So, while I’ll only be discussing the basics of git/using GitHub in this post, the below commands were all I needed during my internship at Google.

Clone

The first step in editing & sharing code in GitHub is to create a repository. Think of a repository as a simple file, which will later contain all of your code files & history for a particular coding project. You can manually create a repository (or as the kids call it, a ‘repo’) by navigating to your GitHub home page and smashing that green ‘NEW’ button. Name your repo something simple, like MyProject.

Clone is a way for you to take that folder from GitHub.com and duplicate it into your computer’s file directory. This will allow you to edit and run your code files from a text editor instead of directly from GitHub, and is how any of your collaborators will be able to access code as well. Cloning means there exist two copies of your project: the one online on GitHub.com to share with the world, and the one on your local computer for solely you to edit and view before choosing to publish.

Similar to how we only post the best photos of ourselves to Instagram, we only push the best versions of our code to GitHub.

git clone https://github.com/YourUsername/YourRepoName.git

After running the above git clone command from your terminal, you will see a new folder entitled MyProject in your local files.

Push

Say I’ve created an index.html file in my text editor and I want to share it on the MyProject repository, so that all my coworkers can see how awesome I am at coding in HTML.

Using the command line, the git status command will notify you of any changes your GitHub repo recognizes in your local folder, that do not yet exist online. Typing git status will display your index.html in red, indicating it has not yet been pushed to your GitHub repo.

git add index.html
git commit -m "added index.html file"
git push

Pushing is a three step process. First, git add index.html to signify that you’d like to add your index.html file to your GitHup repo. Second, git commit -m “message”, replacing the placeholder message with the meaning of your adding this file. It is best to keep commit messages specific, so that when you share your code, coworkers (& your followers) can understand your code creating process exactly. Lastly, git push to send your added files & commit message off to your GitHub repo.

Pull

As mentioned, your project code is simultaneously existing both locally and virtually. What if a colleague updates a file & pushes it to the MyProject repo — how do you ensure you can access this file & work on it, when it does not exist on your local computer?

git pull

The answer is simple: git pull. Pulling from your GitHub repo and into your local computer makes sure that your local folder contains the most recent versions of the files in your repository. If you pull prior to editing any code, you’ll ensure that you’re not making any updates which already exist in your repo.

Checkout & Branches

Most GitHub repositories are initialized with a master branch: Git’s default branch which always points to your last commit. Like the rest of your GitHub work, the master branch exists both locally & remotely, and will point to the respective latest commit. When you are pushing code to GitHub, you will want to stray from pushing directly to master.

Ideally, changes to your code should occur in other branches, to make sure that it is reviewed, working, and readable before being merged to the master branch and located in there.

So, let’s create a new branch and push some code changes to it.

git checkout -b branch-name

The above line would create a new branch in your repository entitled new-branch-name. Once you’ve made changes to your code and are ready to push them, follow the add & commit sequence:

git add .
git commit -m "commit message"

Now, to push your code to this newly created branch, do it as such:

git push --set-upstream origin branch-name

To see in which branch you are currently operating, git status will do the trick. To switch to a new branch, type the command:

git checkout branch-name

You can push and pull code within specific branches, which is ideal when trying to keep your code neat and organized. Eventually, you can merge your branches into the master branch, signifying their code has been approved and is good to go!

Creating and operating within new branches is also ideal when it comes to sharing code, because it allows you to request code reviews on smaller, specific changes. In GitHub, a requested code review is called a ….

Pull Request

Known by its nickname ‘PR’, a pull request is essentially when you ask someone to review code you have committed to GitHub. After pushing code into a new branch, navigate to GitHub.com to view this branch directly from your browser, and you’ll be prompted to create a pull request.

In essence, you’ll be comparing two branches (ideally the one to which you have just pushed new code, versus the master branch), and a reviewer will explicitly see the changes between the two. Later, your reviewer will be able to request changes and eventually approve your code.

Once all of your changes have been approved by your reviewer, you’ll be able to merge your PR, meaning that your code changes are now ready to be added to the main, master branch.

PRs make collaborating in GitHub easier and more efficient, as well as act as error protection to ensure that all code is cross-checked before being officially added to your master branch.

A good rule of thumb when using GitHub: don’t push directly to the master branch. Push to a newly created branch, request a pull request, and only when you’re certain your new code is correct & ready to be published, merge your PR into the master.

Pull

As mentioned, your project code is simultaneously existing both locally and virtually. What if a colleague updates a file & pushes it to the MyProject repo — how do you ensure you can access this file & work on it, when it does not exist on your local computer?

git pull

The answer is simple: git pull. Pulling from your GitHub repo and into your local computer makes sure that your local folder contains the most recent versions of the files in your repository. If you pull prior to editing any code, you’ll ensure that you’re not making any updates which already exist in your repo.

Common Errors

Unable to resolve host

Oftentimes, when I attempt to push code to a repository, I encounter an error message displaying:

fatal: unable to access 'your-repo-url': Could not resolve host: github.com

This simply means that you are operating behind a firewall, and can be easily fixed by switching your WiFi network, or resetting your http proxies:

git config --global --unset http.proxy 
git config --global --unset https.proxy

Diverged Branches

When attempting to commit, you might receive an error message declaring that your branch has diverged from its origin:

Your branch and 'origin/xxx' have diverged,

This error occurs when your local branch is not up-to-date with all the commits existing remotely in this branch (for example, if someone else recently committed to the same branch). The easiest way to resolve this branch conflict is to git pull, or reflect all of the remote changes into your local base. If this pull does not solve the problem, try to rebase your attempted commit to your branch’s remote state:

git rebase origin/your-branch-name 

Reverting Commits

So you’ve made a commit you shouldn’t have… The good news is that GitHub offers a simple, one-liner way to revert any commits you need.

If you type in git log into your command line, you’ll be able to see a history of your commits, and will notice that every commit is identified by a unique ID (an “SHA” or hash). For whichever commit you’d like to revert, copy & paste its unique ID, and type into your command line:

git revert your-commit-id

See? Easy.

Resources

GitHub is an incredibly useful and widely used tool that can also be quite complex and complicated. There is no shame in struggling with GitHub — in fact, everyone who has learned to master it had to start with little knowledge and confusion. With the hopes of expanding the help this blog post might offer, below you’ll find a list of resources I’ve used throughout my GitHub-learning journey, and that will be wonderful tools if you find yourself stuck.

Help with Setting up GitHub

Help with GitHub Branches

GitHub Branches & Master

Glossary of GitHub Terms

Search Engine for GitHub Help

Congratulations, you are now officially tech-savvy.

You can browse my code & projects on my personal GitHub page. A big ‘thank you’ to my mentors at Google who have helped me learn so much about this wonderful tool!