How to get started using GitHub

GitHub is very correctly the warehouse for developers; its where they store their codes. Beyond developers, it is where writers and just about anyone or team who needs to manage different versions of their work on their computer. But very fondly it is called the social network for developers, and this can hardly be more correct. It is one of the largest collaborative platform on the web, recording as high as 40 million users as of August 2019.

As a developer of today, GitHub is the new resume; and if you are not on board, you are missing out on a big important picture. So what is GitHub about? And how do you get started? If you do not know the answer to the above questions, you are not alone. Just relax, these are the questions we look to answer in this article.

First, you need to have understood the concept of “git”. Loosely it is a version control mechanism; a way to updating changes to a project without losing the previous versions. With git, you can track changes as you progress with your project, as opposed to making modifications you cannot reverse or having to create multiple versions of the same project. Also, you can collaborate with other developers to work on the same project. You can learn more about git, its installation, and command line instructions here.

Let us start from the first things

There is a saying that “to make an apple pie, you must first create the Universe”. Similarly, if you must use GitHub, you must first create an account; pretty obvious right? Sign up with a username and email address that would be linked to your Github account.

Just as a side tip, try and pick a username that you would easily remember. Do not bother with “foo” and “bar”, all possible ways of writing those words as a username have probably been exhausted. The platform is free to use, thanks to Microsoft.

When you finish creating your account, you would be able to access it at https://github.com/username.

Ok, I guess you have been good through the process. Let us head to my own account for more clarity.

As you must have observed, my username is ACMoriarty (for the love of Arthur Conan Doyle’s villain), please feel free to use any name of your choice; you cannot change it afterwards though.

Note: You would likely be using Github from cmd, to push or pull codes and files. Whenever you do this, you would have to enter your Github password, except you cache your password by requesting git to automatically authenticate your password.

Next, we look at what follows: how to create your first repo on Github. Ok, its called repository, and it is where you store project files pertaining to a particular project. Within it there could be many branches (different variants of the project).

How to create your first repo

Upon successfully creating your account, you can start pushing files to Github. To do so, you start by creating a repository. On the upper right, click the “+” sign.

From the dropdown, select “new repository”. Once you do this, Github creates a page where you can create and customize your new repository. And one more thing. Github auto-detects your computer’s operating system and renders a corresponding interface; just in case you get something slightly different.

What follows is to fill the fields that result.

Ok, you probably have questions about some of the fields up there. Lets quickly address that before we proceed.

Repository name: This is a name that identifies your project on the Github platform. Github suggests a bunch of random names, but you know best what to name your project so as to mark and remember it. Just do so. For the example repo we are currently creating, the name is set to be “Getting Started With Github”.

Description: This field should contain a brief statement describing the goal of your project. for the example we are creating, we have set that as “Tutorial on how to get started using GitHub”. You can, of course, make it whatever captures the picture painted by your project.

Public vs Private: Github offers free and paid service. The main difference between both is the “Public/Private” feature. For the free service, you only have the option of setting your repo to “Public”, whereas for the paid service, you have the flexibility of setting your repo to either of “Private” or “Public”.

Github of open-source no doubt, except you want extra layers of privacy; then you get to pay. It costs $7 per month for individual developer plan.

Initialize: This portion is totally optional. When creating a Github project, you often want to prepare a kind of document that summarizes the goal of the project, the dependencies used, and instructions as to how other developers can use the project. That is the essence of the README file. You could “initialize with a local README if you wish to.

Do not bother yourself about “.gitignore” for now. While that is outside the scope of our work at the moment, it can be useful later in the future.

Time to take your project from your local machine to GitHub

After you create your project, you can start uploading codes or any files to the repository. Thing is you could do so by clicking on upload from the Github online or you could use command line. The later is what we treat in this post as it is more matured, especially for developers. What is maturity for developers? Haha

To upload the code, you would do a sort of pulling down from online, filling, and pushing back. We will see how it all works shortly. And by the way, this is the model adopted by a good percentage of developers out there, so it would do you some good to understand how it goes.

In what follows, we take grandmotherly steps in setting up our remote online repo from the command line.

  1. I had put a link earlier in this article that would be useful for those who are yet to learn or need to brush up command line commands for git. Using those commands, we would create a project directory called “Getting-Started-Using-Github”.
  2. Use “cd” to change directory into the new folder. Do I repeat this? Change directory into the new folder; people often get errors because they forgot to do this. We would create three vacant files: README.md, index.html, styles.css.
  3. Next, we initialize the new directory in order to make it a local git repository. Do this using the “git init” command.

What have we done? We created a project folder on our Desktop, put in three files in it, and then initialized git using “git init”.

Still using command line instructions, we would go on to stage the files and then commit them. Think of this as packaging the project and stamping them with a sticker with a message (the commit message). The message typically describes what you have done in the project or modified. The first commit you make is usually labeled “initial commit”.

 

 

Ok, let us address two concepts we just mentioned.

  • Staging the project: Packaging everything in the local to upload to the repo is done using the “git add *” command. This is known as “staging”.
  • Committing the project: This is when we save the packaged project and put a stamp on them carrying a message. This is at the heart of versioning, and is done using the ‘git commit -m “First commit” ‘ command.

Next thing is to connect your local Git repo to GitHub

For many people like me, this is where the enchantment all happens. Linking your locally created project to your GitHub repository. Consider this the golden moment when you can move files out and into GitHub as you please.

Let us head back to our repo on GitHub and initialize it. What we get would look something like:

So we are here finally, at the point to push all we have done locally to our remote repo using command line instructions. You would be presented with several options to upload your files. but we would take the easiest way of just clicking on the clipboard and paste on the terminal (i.e “upload a new repository from the command line”). Ensure to type out the instructions patiently, do not give in to the temptation of copy-pasting. By typing the instructions, you train yourself to master them, which would come in handy in time.

  • Adding the Project: The link you have copied would be used as follows: “git remote add origin https://github.com/ACMoriarty/Getting-Started-With-Github.git”. That is “git remote add origin (link)”. This way, you are asking local git to include the link in the project. If you dissect the link, you find that it points to Github, then to ACMoriarty, and then to the remote repository; I think I forgot the .git extension that indicates that you have created a git file.
  • Pushing: Yes, you are giving birth to a brainchild when you push from your local repo. Pushing simply meaning to upload your codes finally. The command line instruction is: “git push -u origin master”. It simply means, in everyday English, upload the code from my local machine (origin) to my Github repo online leaving a master copy there (master).

Great! We made it.

We have uploaded our code successfully. But how do we verify? Multiple ways: either by checking your remote repository or by using the command line instruction “git status”, or simply because no error message popped up.

So check out the result we got first:

First, there is no error. Secondly, you would observe that by typing “git status”, we get:

A message saying “Your branch is up-to-date with ‘origin/master’. Nothing to commit, working tree is clean”. As clean as our work has been so far!

The third way lies on Github. Check your repo to see. For our’s:

That’s all the files we created using command line locally, organized in the order in which they were created.

And there you go! You have just learned all about creating and adding files to your Github repository.

All we have done for the TL;DRs

  • The first step was to create an account on Github, which is an important tool for developers to network and share codes.
  • In our Github account, we created a new repo.
  • We then used command line instructions to initialize git on our local machine, staged the project and committed the files, and finally, we pushed or uploaded the project to our remote repository online.

In diagram:

This diagram nicely summarizes the process; go on to do this over and over. That is the way to master the process. Github can feel exciting the moment you do your very first “git push”.

There are other concepts not covered here you should learn as you go on using Github; like “forking”, “cloning a repository”, “merge conflicts”, and “branching”. These help you collaborate with others basically. What we have covered is sufficient to use Github on your own.

You know what? Create new files and push them to the repository. Do that and keep enjoying the excitement that using Github brings.

Enjoy Git!

advertisement