Git is a distributed version control system

Version Control System

  A version control system allows you to track the history of a collection of files and includes the functionality to revert the collection of files to another version. Each version captures a snapshot of the files at a certain point in time. The collection of files is usually source code for a programming language but a typical version control system can put any type of file under version control. The collection of files and their complete history are stored in a repository.
                                     
The process of creating different versions (snapshots) in the repository is depicted in the following graphic. Please note that this picture fits primarily to Git, other version control systems like CVS don’t create snapshots but store file deltas.
                                                These snapshots can be used to change your collection of files. You may, for example, revert the collection of files to a state from 2 days ago. Or you may switch between versions for experimental features.

Creating snapshots 
 Distributed Version Control System
                                                     In simple version control system, we saw that there will be one central server for storing the repo data. In distributed version control system this central repository server is not necessary. Instead  the user can copy an existing repository. This copying process is typically called cloning in a distributed version control system and the resulting repository can be referred to as clone.
                                     Typically there may be a central server for keeping a repository but each cloned repository is a full copy of this repository. The decision which of the copies is considered to be the central server repository is pure convention and not tied to the capabilities of the distributed version control system itself.  Every clone contains the full history of the collection of files and a cloned repository has the same functionality as the original repository.
 
                                               The core of Git was originally written in the programming language C, but Git has also been re-implemented in other languages, e.g. Java, Ruby and Python. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005,

 Local Repositories

                                                     After cloning or creating a repository the user has a complete copy of the repository. The user performs version control operations against this local repository, e.g. create new versions, revert changes, etc.
You can configure your repository to be a bare or a non-bare repositories.

  • bare repositories are used on servers to share changes coming from different developers
  • non-bare repositories allow you to create new changes through modification of files and to create new versions in the repository

If you want to delete a Git repository, you can simply delete the folder which contains the repository.

 Remote Repositories

                                                   Git allows the user to synchronize the local repository with other (remote) repositories. Users with sufficient authorization can push changes from their local repository to remote repositories. They can also fetch or pull changes from other repositories to their local Git repository.

 Branching
                                         Git supports branching which means that you can work on different versions of your collection of files. A branch separates these different versions and allows the user to switch between these version to work on them.

Working tree
                                                       The user works on a collection of files which may originate from a certain point in time of the repository. The user may also create new files or change and delete existing ones. The current collection of files is called the working tree.
A standard Git repository contains the working tree (single checkout of one version of the project) and the full history of the repository. You can work in this working tree by modifying content and committing the changes to the Git repository.
                                             
                                     If you modify your working tree, e.g., by creating a new file or by changing an existing file, you need to perform two steps in Git to persist the changes in the Git repository. You first add selected files to the staging area and afterwards you commit the changes of the staging area to the Git repository. The staging area term is currently preferred by the Git community over the old index term. Both terms mean the same thing.
                                   
 Adding to staging area
                                         We can add changes in the working tree to the staging area with the git add command. This command stores a snapshot of the specified files in the staging area.
The git add command allows you to incrementally modify files, stage them, modify and stage them again until you are satisfied with your changes.

Committing  to the repository 
                                                   After adding the selected files to the staging area, you can commit these files to permanently add them to the Git repository. Committing creates a new persistent snapshot (called commit or commit object) of the staging area in the Git repository. A commit object, like all objects in Git, are immutable. The staging area keeps track of the snapshots of the files until the staged changes are committed. For committing the staged changes you use the git commit command.