Distributed version control system
Introduction
GitHub ≠ git
Git is a version control system. However, git themselves describe as “Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.” . First look on the description of this software will not attract a developer towards the distributed nature. We mean it in the way that developer will well overlook the fancy (sarcastically! fading away in fashion) word in the description. This is the reason we started with correct but not accurate statement for this dispatch.
Given the attention span for developers overlooking the nature of distributed revision management let us begin to understand that given no developer would really need an introduction to revision / version control system.
Put simply the distributed nature of the software allows developer to maintain a local copy of server copy and perform all operations to it as if the server was available always irrespective of the network status. There is a popular story that Linus Torvalds started to develop git to address the problem of him being able to work and maintain versions while he is transiting between places, while he is in-flight, while he is on networks of poor quality which hindered his productivity.
Having talked about git and its distributed nature now let us focus on another major confusion for the developers. We opened this dispatch with that statement GitHub and git are different. GitHub is a hosting platform which in its core has a git which is slightly different from the git created by Linus Torvalds . One can vaguely visualize this relationship in the following manner –

Developers take
We will not sermonize the necessity to have git. Nor we will emphasize the source code management philosophy. Neither will we preach the necessity of discipline by developers while they construct the cathedrals.
We will focus on what git offers how it will be of relevance to you – {Developer}.
Before you get to the actuals take the following facts as given –
1. git is a stand-along application as well as client which can connect to a server i.e. a hosted solution e.g. GitHub.
2. GitHub, TFS, BitBucket are hosting system which in their core use git.
3. Every folder where you run the command git init is a server. Anyone who has access to this folder can commit and checkout code. This is the reason it is = DISTRIBUTED
4. git does not need a central server to work, thereby you can even carry it in pen drive
5. git is a folder system which can be inspected using software like folder explorer in a windows operating system
6. git has the same lifecycle as the centralized version control system

Knowing the directions
Once you have installed the git from the binary distribution location here – https://git-scm.com/. Before we dive in on the usage of git. First order of work is to settle the confusion on git cannot be used alone in single developer machine.
Using fact #1 were we state git is a stand along application. It is very much possible that a developer wants to have the ability to go back in time to the code base as it was without being connected to a GitHub or any other such server.
If for a moment you rethink the way developers before git used to use SVN or even before CVS it will become obvious. i.e. you would have to install a server and run the windows service. There will be a command line client which will connect on either svn: protocol (for SVN) or on http: protocol (for svn and cvs) to maintain the commits.
With git it is not required. All you need is the git binary distribution which you just installed.
Getting started is very easy. First thing first; start with configuring. Generally, this is a boring step for the developer. However, it is minimal in git. You would need to run these commands in the command prompt –

git config –global user.name = “Siva Senthil”
git config –global user.email = “siva.senthil@vos.com”

One doubt which perplexed me when I started was the misinterpreted association of these details with the login credentials used to connect to a hosted git server e.g. GitHub or BitBucket etc. So, here is the clarification I learnt by using git. These has got nothing to with any credentials. These are the information required to store a commit in the git. So, that a commit will look like this –

commit ac4bdd2dbb58781e253dcd24cf86977d54e9dae0 (HEAD -> master, origin/master, origin/HEAD)
Author: Siva Senthil <siva.senthil@vos.com>
Date: Sun Jun 10 20:30:05 2018 +0530

Added code to ensure tests succeed. Note the Cmdlet depends on -Raw switch.

The bread & butter
With configuration done we are good to lead the life in simplistic manner. Follow these sequences of commands to initialize, include all files, and bring it under revision control in your own desktop without any central server –

# initialize git in a folder; irrespective of whether the folder has content (files) or not

git init

# add all files in the folder to the git revision control on your desktop

git add *

# commit the files to git

git commit -m “Added code to ensure tests succeed. Note the Cmdlet depends on the -Raw switch”

The above sequence of steps will lead us to the same log which you saw few lines above. Now the natural succeeding question is how do I check the revisions I have committed

# to inspect the revisions committed to git

git log

Is this all to know in git? Yes, practically this set of commands are more than sufficient for a developer to survive the first day. To propel yourself along with a team of developers you would few additional commands and to synch with a server you would couple of more.
Let that be a dispatch for another day. For now, we want this to be focused on a single developer using git to have the revisions stored and be able to go back in time and learn from his/her own code in the past.
Having said that if you deploy git for the sole purpose of yourself being able to go back in time and learn from your past; it will imbibe the core discipline required for you to survive within the team of developers who are collaborating code to build the cathedral .