Basic concepts of Git and Github

**Basic concepts of Git and Github.**

**What is Git?**
Git is a decentralized version control system with the goal of allowing developers to keep track of/revert changes, work on different versions of the software at the same time, merge changes together etc.
GitHub is just a site to store *Repositories* online, it's not integral to git.


The **Repository** is the place where you store your work. At first, it’s a folder on your computer. When you add version control, the folder becomes a repository and can keep track of the changes you make.
A folder becomes a repository after you *init* git inside it (either with the init command line command or though a GUI program). This will generate a hidden `.git` folder inside the top level directory efficiently containing all the data of the changes you will make later.

Usually the Repository will also be a **Working Directory**, where the actual working code is and where you want changes to be tracked/reverted etc. 
Changes are either: new files, deleted files or modified files.

Git will not automatically record all the changes you make, you need to actually **commit** them to save the state in the local repository. To commit there is an additional step of selecting and **Staging** exactly which changes are actually to be recorder. After that the staged changes can be Committed with a message describing the nature/reason of the change.

So basically git shows you all the changes your working copy has from the last commit and you can decide whether to revert these changes or commit them.

But what if you want to use an old version of the code that you have committed? You can do that by **checking-out** a particular commit in the history. The state of your Working Copy will be set to how it was at the time of that commit (be sure to not have uncommitted changes).

Now you can do other changes and git will show the differences from that particular commit you have checked out.

Now for the really powerful thing that git allows you to do, **Branches**. You can create new *Branches* of your code with different commits on them. You can switch between them by checking out one branch or another. You can later **Merge** a branch into another and git will do so automatically unless there are changes that conflict one another. In that case you will be asked to select what to do either using one version or the other, or manually editing for a satisfactory result.

What if more people are working on the same project? Git repositories can be cloned, so each collaborator can have a complete copy of all the changes. Then using Merging the changes from each developer can be integrated back into the other repositories.

Here is where GitHub comes in, offering a place where to store Repositories online so that devs can easily share work.
With a central online repository on github the workflow changes a little.

A local repository's changes (new history etc) can be **Pushed** to the *Remote* (github) by the owner of the remote.
A collaborator can then **Pull** these new changes from the Remote to their local repository.

Now if you are an external collaborator and don't have write permission on the github remote you can't directly *push* your changes to it, you need to ask the owner of that repository to *Pull* in your changes by making a **Pull Request**. To make a Pull Request from github you need to have your own version of the same github repository a so called **Fork**. So you fork the GitHub repo to have your own remote where you can Push your changes, then from that Fork you can create a Pull Request to the original GitHub repo.