Version control systems

Version control systems are a category of software tools that helps in recording
changes made to files by keeping a track of modifications done in the code.
Why Version Control system is so Important?
As we know that a software product is developed in collaboration by a group of
developers they might be located at different locations and each one of them
contributes to some specific kind of functionality/features. So in order to
contribute to the product, they made modifications to the source code(either by
adding or removing).
A version control system is a kind of software that helps the developer team to
efficiently communicate and manage(track) all the changes that have been made
to the source code along with the information like who made and what changes
have been made.
A separate branch is created for every contributor who made the changes and the
changes aren’t merged into the original source code unless all are analysed as
soon as the changes are green signalled they merged to the main source code. It
not only keeps source code organized but also improves productivity by making
the development process smooth.
Basically Version control system keeps track on changes made on a particular
software and take a snapshot of every modification. Let’s suppose if a team of
developer add some new functionalities in an application and the updated version
is not working properly so as the version control system keeps track of our work
so with the help of version control system we can omit the new changes and
continue with the previous version.
Benefits of the version control system:
 Enhances the project development speed by providing efficient
collaboration,
 Leverages the productivity, expedites product delivery, and skills of the
employees through better communication and assistance,
 Reduce possibilities of errors and conflicts meanwhile project development
through traceability to every small change,
 Employees or contributors of the project can contribute from anywhere
irrespective of the different geographical locations through this VCS,
 For each different contributor to the project, a different working copy is
maintained and not merged to the main file unless the working copy is
validated. The most popular example is Git, Helix core, Microsoft TFS,
  Helps in recovery in case of any disaster or contingent situation,
 Informs us about Who, What, When, Why changes have been made.
Use of Version Control System:
 A repository: It can be thought of 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.
 Working in a group: Consider yourself working in a company where you
are asked to work on some live project. You can’t change the main code as
it is in production, and any change may cause inconvenience to the user,
also you are working in a team so you need to collaborate with your team
to and adapt their changes. Version control helps you with the, merging
different requests to main repository without making any undesirable
changes. You may test the functionalities without putting it live, and you
don’t need to download and set up each time, just pull the changes and do
the changes, test it and merge it back. It may be visualized as.
Types of Version Control Systems:
 Local Version Control Systems
 Centralized Version Control Systems
 Distributed Version Control Systems
Local Version Control Systems: It is one of the simplest forms and has a
database that kept all the changes to files under revision control. RCS is one of
the most common VCS tools. It keeps patch sets (differences between files) in a
special format on disk. By adding up all the patches it can then re-create what any
file looked like at any point in time.
Centralized Version Control Systems: Centralized version control systems
contain just one repository globally and every user need to commit for reflecting
one’s 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
 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 others’ 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, and Mercurial.
They help us overcome the problem of single point of failure.

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 cases, 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.

What is a GIT Repository?

GIT contain a collection of files of various different versions of a Project. These
files are imported from the repository into the local server of the user for further
updations and modifications in the content of the file. A VCS or the Version
Control System is used to create these versions and store them in a specific place
termed a repository. The process of copying the content from an existing Git
Repository with the help of various Git Tools is termed cloning. Once the cloning
process is done, the user gets the complete repository on his local machine. Git
by default assumes the work to be done on the repository is as a user, once the
cloning is done. Users can also create a new repository or delete an existing
repository. To delete a repository, the simpler way is to just delete the folder
containing the repository. Repositories can be divided into two types based on the
usage on a server. These are:
 Bare Repositories: These repositories are used to share the changes that
are done by different developers. A user is not allowed to modify this
repository or create a new version for this repository based on the
modifications done.
 Non-bare Repositories: Non-bare repositories are user-friendly and hence
allow the user to create new modifications of files and also create new
versions for the repositories. The cloning process by default creates a non-
bare repository if any parameter is not specified during the clone operation.
 Working Area or Staging of a Git Repository
A working tree in a Git Repository is the collection of files which are originated
from a certain version of the repository. It helps in tracking the changes done by
a specific user on one version of the repository. Whenever an operation is
committed by the user, Git will look only for the files which are present in the
working area, and not all the modified files. Only the files which are present in
the working area are considered for commit operation. The user of the working
tree gets to change the files by modifying existing files and removing or creating
files. There are a few stages of a file in the working tree of a repository:
 Untracked: In this stage, the Git repository is unable to track the file,
which means that the file is never staged nor it is committed.
 Tracked: When the Git repository tracks a file, which means the file is
committed but is not staged in the working directory.
 Staged: In this stage, the file is ready to be committed and is placed in the
staging area waiting for the next commit.
 Modified/Dirty: When the changes are made to the file i.e. the file is
modified but the change is not yet staged.
After the changes are done in the working area, the user can either update these
changes in the GIT repository or revert the changes.
Working with a Repository
A GIT repository allows performing various operations on it to create different
versions of a project. These operations include the addition of files, creating new
repositories, committing an action, deleting a repository, etc. These modifications
will result in the creation of different versions of a project.
Adding to a Repository
After performing various modifications on a file in the Working Area, GIT needs
to follow two more steps to save these changes in the local repository. These steps
are:
1. Adding the changes to the Index(Staging Area)
2. Committing the indexed changes into the repository
Adding changes to the Index This process is done by the use of git add
command. When the changes have been made in the Working Tree/Area. These
changes need to be added to the Staging Area for further modification of the file.
git add command adds the file in the local repository. This stages them for the
commit process.
Syntax:
$ git add File-name
Different ways to use add command:
$ git add .
To add a specific list of files to the staging area.
$ git add --all
To add all files of the current directory to a staging area.
$ git add *.txt
To add all text files of the current directory to staging area.
$ git add docs/*.txt
To add all text files of a particular directory(docs) to staging area.
$ git add docs/
To add all files in a particular directory(docs) to staging area.
$ git add “*.txt”
To add text files of entire project to staging area. Committing changes from the
Index Committing process is done in the staging area on the files which are added
to the Index after git add command is executed. This committing process is done
by the use of git commit command. This command commits the staged changes
to the local repository. Syntax:
$ git commit -m "Add existing file"
This commit command is used to add any of the tracked files to staging area and
commit them by providing a message to remember.

Synchronizing with Remote Repositories

Git allows the users to perform operations on the Repositories by cloning them
on the local machine. This will result in the creation of various different copies
of the project. These copies are stored on the local machine and hence, the users
will not be able to sync their changes with other developers. To overcome this
problem, Git allows performing syncing of these local repositories with the
remote repositories. This synchronization can be done by the use of two
commands in the Git. These commands are:
 push
 pull
Push: This command is used to push all the commits of the current repository to
the tracked remote repository. This command can be used to push your repository
to multiple repositories at once. Syntax:
$ git push -u origin master
To push all the contents of our local repository that belong to the master branch
to the server(Global repository). Pull: Pull command is used to fetch the
commits from a remote repository and stores them in the remote branches. There
might be a case when other users perform changes on their copy of repositories
and upload them with other remote repositories. But in that case, your copy of the
repository will become out of date. Hence, to re-synchronize your copy of the
repository with the remote repository, the user has to just use the git pull
command to fetch the content of the remote repository. Syntax:
$ git pull
Some more commands:
Git Status: It is used for checking the status of git repository, i.e., if the files are
committed or not, files in staging area or untracked file.
$ git status
Git Log: It is used to track all the changes made, and by whom. Its command is
$ git log
.gitignore: You may use .gitignore if you want to hide any file when uploading
online. Just simply create a .gitignore file, and write all the files names you want
to ignore.
Git Merge: It is used to merge two repository, without losing the data. It merge
the specified repository to the current repository.
$ git merge <repo-name>
Git Checkout: It is used to rollback to previous version of the project which was
committed anytime earlier. You can copy to hash-code from git log and use it to
rollback. Let’s have a look over the code:
$ git checkout <hash-code>