GitHub 101 — Introduction to GitHub for Newbies

This article is the second in a series of articles to explain Git and GitHub in an easier-to-understand manner. The previous article gave a gentle introduction to Git for Newbies. If you’re not familiar with Git, do us both a favor and check out the first article before reading this. It’s just about 5 minutes.

Up to speed? Yas!!! Now, let’s get to the matter. In a hurry? The meat of this matter is here.

In the last article, we said you can share your “git-tracked” folders (AKA local git repositories) with friends, colleagues and even strangers. What we didn’t say was that GitHub makes that a ton easy.

Oh oh. Let’s pause for a moment. While this article is primarily focused on GitHub, the same principles apply for any other git hosting platform or service out there. Examples of such other platforms/services are GitLab and Bitbucket.

Okay, let’s continue.

Github defines GitHub as “a code hosting platform for version control and collaboration. It lets you and others work together on projects from anywhere.”

Simple enough? I hope so. But just in case…

GitHub helps you keep your “git-tracked” project folder (AKA local git repositories) and all its contents in the cloud so you or anyone else you permit, can access it from anywhere, anytime. Well, basically.

The most common use of GitHub and other git hosting platforms/services is simply keeping copies of local git repositories in the cloud, so if/when you lose your PC or some other sh*t happens, you don’t have to bite your finger.

Aside that, there is yet another benefit such platforms/services provide — collaboration! The ability to have others join you in a project either making direct changes to the files or reviewing your work and suggesting improvements, reporting bugs etc. In a subsequent article, we’ll look at how to use GitHub for effective collaboration.

For now, let’s look at how to synchronize your local repository with GitHub. As you know, synchronization is a 2-way thing. Your local repository sends updates to the remote repositories whenever there’s a change locally (called pushing), and you can fetch updates from remote repositories if there’s a change in the cloud that you do not yet have locally (this is called pulling).

Getting Started with GitHub

Head over to GitHub and create an account — or login if you already have an account. Then create a new project (or repository). It’s usually better to create new projects without initializing the repository with a README.md file.

When done, you’ll be given a unique URL for the project that looks like what we have below. Copy it! No, I don’t mean copy the URL below. Copy the URL given to you 😉.

https://github.com/itswisdomagain/firebase-auth-secure-way.git

Return to your terminal/command prompt and tell Git you want to synchronize your local repository with GitHub. Remember to navigate to your project directory on the terminal/command prompt before executing any git commands. The command you need to connect your local git repository with the cloud repo hosted by GitHub is:

git remote add origin https://github.com/itswisdomagain/firebase-auth-secure-way.git

2 things to note. First, the origin keyword you see is just an identifier. Git allows you to connect more than 1 remote repository to your local git setup. Git requires you to give each remote repo (repo is the same thing as repository) a unique ID. Its’s common practice to use origin as the identifier for the default remote repository.

The second thing to note should be obvious, but I’ll just say it. The URL! The command should end with the URL you copied earlier and not the one I used in that example.

Alright, once you’ve executed that command, Git knows that there is a remote repository that it should sync with. But Git does not automatically sync whenever you make a commit. You have to specifically instruct Git to do so before it does.

PUSHING to the cloud

To upload your local changes to the remote repository for the first time, enter the following instruction on your terminal/command prompt:

git push -u origin master

The keyword origin in this command is the unique identifier of the remote repository you want to send updates to. The unique ID you set earlier, remember?

The keyword master indicates the branch in the remote repository you want to push updates to. The default branch is master. Just leave that untouched for now. In the next article, we’ll talk about Branches in Git and GitHub.

The flag -u stands for set-upstream. It tells Git that it should remember this remote repository ID and branch name for subsequent pushes.

After that first time, you can just use the following command to subsequently push local changes to the remote repository:

git push

PULLING from the cloud

We did say synchronization is a 2-way thing. There are times when the project repo on GitHub contains updates that we do not have locally.

Maybe you worked on the project from the office and pushed the changes you made to GitHub. And now you want to continue working on the project from your personal PC and you realize you don’t have the latest update in your PC. Oh please, stop copying project files in a flash drive from the office PC to your personal PC and back 🙄🙄.

Or maybe it was your colleague that pushed the last update to the project repository on GitHub.

So, fine, someone pushed to GitHub or whatever, point is, you don’t have the latest updates on your current PC. But you have an older update. And your project folder is connected to the remote GitHub repo. No problemo. Let me show you how to update your local repository with changes from GitHub.

Quite simple really. Just execute the following command in terminal/command prompt:

git pull

If that doesn’t work out of the box, try:

git pull origin master

As usual, the origin in this last command is the unique ID of the remote repo while master is the name of the branch we’re pulling from.

And voila, you now have the updated copy of the project, along with the entire commit history!

Important note:

Before you can successfully push to, or pull from a remote repo, your local repo must have gotten the latest updates in the remote repo. If there’s an update in the remote repo that you had not pulled, you’d need to pull before you can push.

That’s GitHub in a nutshell. As you might have guessed, Git and GitHub have even more exciting features. Subsequent articles of this series will give attention to them…

In the meantime, do leave some claps if you enjoyed reading this article. Do not hesitate to drop any thoughts or questions you may have in the comments section.

Yours truly.