A gentle introduction to Git and GitHub

A gentle introduction to Git and GitHub — the ELI5 way

A software development team generally comprises of two or more individuals working on the same codebase for a particular project. This makes it important for a developer to be aware of the new changes made by the rest of the team over time in an easy to understand and hassle-free manner.

This where the concept of a Version Control System (VCS) comes in handy. Git is a widely used VCS for software development.

Through this powerful yet simple mechanism, all the team members are able to work on a single code base (a.k.a. the master branch) through a well-documented approach.

xkcd ❤ btw git isn’t complicated at all

What is a Git Repository?

A Git repository refers to an online container where your source-code can be stored, contributed to, and managed over time. It is analogous to a smart folder on your workstation which keeps track of all the changes that has been made to it ever since its initiation.

If you have a proper understanding of the structure of your repository, you can build on top of your existing code, rather than starting from scratch and running it by others in a weird manner.

How to set-up a Git Repository on GitHub

GitHub landing page after logging in

After clicking on New, you are given the following fields to fill and initialize your new repository. The repository could either be Private (restricted to contributors only) or Public (freely available to all).

The README file is one of the most important markdown files in your repository. As a best practice, you should always populate it with text that is indicative of your progress, debugging information, or as a general (or comprehensive) guide to how visitors can run your project on their personal workstations. Once done, you are greeted with the repository.

GitHub Repository landing page

Basic Workflow of a GitHub Repository

Cloning (downloading) your repository

Cloning a repository

You could either simply download your repository using the Download ZIP option or introduce yourself to a world of limitless possibilities by using the Command Line Interface (CLI) for Git. If you don’t already have Git installed on your system, you may refer to this amazing guide here.

Cloning a GitHub repository using CLI

CLI Command: git clone <repository-url> <destination-directory>

The following example illustrates a simple cloning of the repository using just the URL. But in case you want to put the entire structure into a folder name of your choice, you could add the destination directory parameter as well.

What are Remotes?

In contrast to a local repository (offline), a remote is a reference to a repository which is hosted on a cloud platform used by GitHub. https://github.com/ss-is-master-chief/MyGitHubRepository.git is an example of such a repository we have created previously and can be referenced using the URL.

But it is tedious to use the entire URL every time we need to perform an operation via git. This is where we could assign an alias to the repository URL for our convenience. By default, the URL is referred to as origin and can be changed if necessary.

1. Fetch refers to obtaining/downloading the changes/data from the server which houses our repository.
2. Push refers to uploading the changes/data from our local machine to the server which houses our repository.

For demonstration purposes, let’s say we wish to add another remote called upstream which is an alias to the same URL — https://github.com/ss-is-master-chief/MyGitHubRepository.git

It is a good practice to use the upstream remote to fetch files from our main repository (might be someone else’s version) and push to our own repository called origin.

Let’s talk about Branches

If you head over to your GitHub Repository and click on Branch, you’ll be shown a list of branches which you (or contributors) have created. Currently, since we have just set up the repository, you’d be shown only one i.e. the master. The master branch is the main branch on which your final code is supposed to exist.

Now, what if you have a feature in mind which is yet in its experimental phase? This is where creating and working on a new branch comes into the picture.

A `Branch` is a new track which starts off with the current master code as it’s base code. It has been demonstrated via the following diagram. You may work on the new branch called BigFeature, without affecting your main code-base. The two branches master and BigFeature can be worked on independently.

In the command line, we can use the command git branch to return all the branches we currently have. The * refers to the branch we are currently working on.

We use the CLI Command:git checkout -b <Branch-Name> to create a new branch.

We can also switch to another branch using the command git checkout <Branch-Name>. If we wish to delete a branch, we may use git branch -D <Branch-Name>

Let us set up a branch using the Git CLI.

The above changes have been carried out locally. This means that nothing has yet been reflected back to our GitHub (online) repository.

Let us create another branch called test, make some changes to it and upload it to our main repository.

What are Git States?

Git States refer to which state your modified files are currently in. For example, once you have made some changes to the `README.md` file, the file is now `modified`. But this doesn’t mean, we can upload the changes to the repository right away. To ensure a procedure which confirms your changes, we have to add the modified files to the staging area.

Consider an example of 10 students sitting in an auditorium. Out of them, 5 of them are told to dress up i.e. modified and asked to go up to the stage. This means that the 5 students are in the staging area. Now, the students are ready to perform i.e. commit to the play.

Let’s represent this scenario via Git. We will make some changes to the README.md. We have added the line “These are some changes” to the end of the file.

We can check what the changes were using the CLI Command: git diff

To check which files were changed, we can use the CLI Command: git status. It will return the status of the staging area. In the following demonstration, we notice that `README.md` is tagged as `modified` and represented in color `RED` (in your terminal window).

Now we shall add the changes (of our choice) to the staging area. Basically, we are trying to curate the changes (but maybe not all) we want to upload to the repository. We will use the CLI Command: git add <file-name>. The modified tag will now be changed to `GREEN` (in your terminal window).

Once we have added the files, we will commit (upload) the changes to the master branch of our repository.

Merging

Let us create a new branch called new_branch and make some changes to it by creating a new file called new_branch_file.txt. We have added the line “This is a new branch file” to the new_branch_file.txt.

The two branches master and new_branch are independent of each other. Changes in the new_branch will not be reflected in master until we want it to. Independence has been demonstrated in the following snippet.

Your repository landing page shall indicate if there are any changes between the master and any other branches created by you or any of the other contributors to your project.

Through the Pull Request mechanism, you can review the changes proposed by a developer. Moving on, you could either let it slide or merge it into the destination repository.

Merging the CLI way

Phew.. that was a lot.

Thank you for reading my attempt at explaining how you could get started with Git and GitHub. Please feel free to comment on how I should improve my writing, and Clap-n-Share if you loved it!