Understanding GITHUB

Understanding GITHUB

What is GitHub?

GitHub is made up of two main aspects. 

1. It is a cloud storage for your repositories and it is built upon on and integrated with Git so it is a fantastic tool for Version Control.
   
   
2. It is a web based platform built for collaboration with others, whether it is a group of colleagues in a small team in a company or a group of strangers spread across the world.

We will focus mainly on GitHub in this blog and keep Git as a future topic to be discussed.

CREATING A REPOSITORY

Creating a repository named Test_template

Here I am creating a new repository on GitHub with the option of Public sharing meaning anyone can try to collaborate with me on this repo whereas private option is usually for personal work not meant to  be shared or a project developed by a small team in a company. 

You see a 'Add a README file' option turned on. What is a README file? It is basically the first thing that pops up when someone clicks on the repo. It is a markdown (.md) file and contains information on the project which can range from the technologies being used, purpose, installation steps, contribution guidelines. Essentially it is a very important part of the repo.

After clicking on create repository, your screen should refresh to this:

COMMIT

Let say I have written a small sentence in the README file of my repository. N
ow I want to save the change I have done. To save a change in GitHub means to 'commit' it. Usually when performing a commit, you will add a message alongside it and it is very important as it helps any collaborator or even your future self understand the change you have made.

BRANCH, PULL REQUEST and MERGE

A fundamental concept of GitHub is branching. Branch essentially is the idea that you create a separate version of your repository. It is still located in your primary/default repository which is the one that we created and that primary repo is usually known as 'Main' Branch.

However a neat feature of branch is the separate repo does not affect 'Main' Branch so it is very useful for parallel development to create new or and bug fixes.

Now let say that we have created a new branch called 'feature1' and you have written a small sentence in the README file for that branch. We committed the change but now we want to integrate the change we made in the 'feature1' to the 'Main' branch. This is usually one of the goals of a managing a project on GitHub. To do so we use Merge option.

Before performing merge, we need to go through a pull request. What is a pull request (pr)? 

It refers to two things:

1. The act of proposing changes to a shared repository. This is done by contributors.
   
   
2. The review of the said changes and preparing it to merge to main branch. This is done by the repo owner or an equivalent member.

If your pull request is valid and accepted by the repo owner, it will be merged. In this situation I am the owner and I will be accepting my own pr and merging it.

CLONE and FORK

Both clone and fork create a copy of a repository but they have different purposes.

Clone creates an exact copy of the repository on your local machine not on the website server. It allows you to edit the files in your usual editor and Git is used to track the changes. After committing changes to your repo in the local machine, you can send it to the remote repository (GitHub). This is called a Push. 

The opposite to Push is Pull meaning you are taking in the changes done by a contributor in the remote server and putting it in your local machine.

Fork is a copy of a repository that stays on your GitHub account. It is usually done when you do not have write access to the original repo but you want to make changes on the project and this will not affect the original repo. Later on you can open a pull request if needed.