#1. What is GIT ?

Read time : 5-6 minutes

GIT is a free, open-source distributed version control system. It keeps track of projects and files as they change over time with the help of different contributors.

Version Control in Git ?

Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. For the examples in this book, you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer.

Use of Version Control System:

Repository : It can be thought as a database of changes. It contains all the edits and historical versions (snapshots) of the project.

Copy of Work (sometimes called as checkout):  It is the personal copy of all the files in a project. You can edit to this copy, without affecting the work of others and you can finally commit your changes to a repository when you are done making your changes.

Types of Version Control System :

• Local Version Control Systems
• Centralized Version Control Systems
• Distributed Version Control Systems

Local Version Control Systems : Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to.

To deal with this issue, programmers long ago developed local VCS's that had a simple database that kept all the changes to files under revision control.

#1. Local Version Control Systems

Centralized Version Control Systems : Centralized version control systems contain just one repository and each user gets their own working copy. You need to commit to reflecting your changes in the repository. It is possible for others to see your changes by updating.

Two things are required to make your changes visible to others which are:

• You commit
• They update

#2. Centralized Version Control Systems

The benefit of CVCS (Centralized Version Control Systems) makes collaboration amongst developers along with providing an insight to a certain extent on what everyone else is doing on the project. It allows administrators to fine-grained control over who can do what.

It has some downsides as well which led to the development of DVS. The most obvious is the single point of failure that the centralized repository represents if it goes down during that period collaboration and saving versioned changes is not possible. What if the hard disk of the central database becomes corrupted, and proper backups haven’t been kept? You lose absolutely everything.

Distributed Version Control Systems: Distributed version control systems contain multiple repositories. Each user has their own repository and working copy. Just committing your changes will not give others access to your changes. This is because commit will reflect those changes in your local repository and you need to push them in order to make them visible on the central repository. Similarly, When you update, you do not get other’s changes unless you have first pulled those changes into your repository.

To make your changes visible to others, 4 things are required:

• You commit
• You push
• They pull
• They update

The most popular distributed version control systems are Git, Mercurial. They help us overcome the problem of single point of failure.

#3. Distributed Version Control Systems

                                

Purpose of Version Control:

• Multiple people can work simultaneously on a single project. Everyone works on and edits their own copy of the files and it is up to them when they wish to share the changes made by them with the rest of the team.
• It also enables one person to use multiple computers to work on a project, so it is valuable even if you are working by yourself.
• It integrates the work that is done simultaneously by different members of the team. In some rare case, when conflicting edits are made by two people to the same line of a file, then human assistance is requested by the version control system in deciding what should be done.
• Version control provides access to the historical versions of a project. This is insurance against computer crashes or data loss. If any mistake is made, you can easily roll back to a previous version. It is also possible to undo specific edits that too without losing the work done in the meanwhile. It can be easily known when, why, and by whom any part of a file was edited.

Repository in Git ?

A repository (commonly referred to as repository) is a collection of source code. A repository has commits to the project or a set of references to the commits (i.e., heads).

Commits in Git ?

A commit logs a change or series of changes that you have made to a file in the repository. A commit has a unique SHA1 hash which is used to keep track of files changed in the past. A series of commits comprises the Git history.

Branches in Git ?

A branch is essentially a unique set of code changes with a unique name. Each repository can have one or more branches. The main branch — the branch where all the changes eventually get merged into - is called the master. This is the official working version of your project and the one that you will see when you visit the project repository at http://www.github.com/yourname/projectname.

Working directory, staging area, and local repository in Git: 

Every local repository has three different virtual zones. These are:

• Working directory
• staging area
• commit area.

The working directory is where new files are created, old files are deleted, or where changes are made to already existing files.

Once changes are made, they are added to the staging area. The staging area is also sometimes called the index.

Once the changes are complete​, the staging area will contain one or more files that need to be committed. Creating a commit will cause Git to take the new code from the staging area and make the commit to the main repository​. This commit is then moved to the commit area.

Conclusion : 

This is all about Git (in theory). In next post  we will see how to use git in out working project and we will also focus on the following points :

• How to use Git in live project.
• How to integrate git into a non git project.
• How to create branches.
• How to create a pull request.
• How to create commit code.
• How to merge code into master branch.

---

For more updates please follow us on :

Twitter      : https://www.twitter.com/dorado2041
Facebook  : https://www.facebook.com/dorado2041
Instagram : https://www.instagram.com/dorado2041
Blogger      : https://doradosolutions.blogspot.com