Need of “unDo” in software development

Build 1 Testing Deployment

c
h U
a n
n |
g d
e o

Build 2 Testing Deployment

• How to “revert-back” to “previous-version”???

“Version” control/ “Re-vision” control/
“SubVersion” control
• Version control or Revision control is a process
in which “state” or version of a software is
continuously tracked.

• This system records each and every changes to

a file or set of files, so that we can revert to
previous version/state whenever needed.
 local Version Control (VCS) System
• Local VCS is the simplest one, in which a
programmer copies the files into a time-stamped
directory.

• Hence whenever needed, any version of the files

can be used.
• But the above process is error-prone and cannot
be used if more than one programmer is working
in the project. Even worse if they are not working
in same place!!!!
• Now there is a need of “Centralized Version
Control System”
 Centralized Version Control System
• In Centralized VCS, there is a centralized repository
which contains all versions (set of files) of a software
product.

• The clients which are connected to

it, can push or fetch any product
version by remote access.

• The process through which files are “pushed” in this

repository is called “Checked-in”.

• The process through which files are “fetched” from

the repository for further editing is called “Checked-
out”
 Limitation of Centralized VCS
• There are two major draw-back of centralized VCS :

1. All files are on centralized repository,

if the server is down for any period of
time, no programmer can perform
check-in or check-out.

2. If the hard-disk of centralized server gets corrupted, then

the entire history of the project is gone and we will loose
everything.

To deal with above problems a new type of VCS is developed

which is known as “Distributed” VCS.
 Distributed Version Control System
• In Distributed VCS, whenever a client machine fetched out
the latest files from centralized repository, it actually fully
mirrors the whole project repository.

• Hence in this system, each client machine is a complete

backup of the project.
• If centralized repository fails, any client repository can be
copied to server in order to restore the project.
• In this every check-out is a full backup.!!!
This is where “GIT” step in….
• GIT is basically a distributed VCS, in which all files of a
particular project is stored in a centralized GIT server.
• It is a tool which manages source code history.

• The working of GIT is totally different from how other

Centralized VCS works.

• Whenever a client checked-out the files, the whole

project is copied to the client-machine in a hidden
folder and compressed form.
 GIT installation on Windows
GIT installation on windows is quite easy and
straight forward. Steps are as follows :
1. Go to http://msysgit.github.io/ and download
the GIT installer package.
2. During installation select “use GIT Bash only” as
it will not modify our system path variable.
3. Once it is installed we will get both command
line version known as “GIT bash” and GUI
version known as “GIT GUI”.
4. In order to check the setting of GIT just run the
following command in GIT bash :
“git config --list”
 Creating a GIT repository
• A GIT repository is nothing but the collection of
files and their history.

• There are two ways through which a GIT

repository can be created :
1. Create GIT repository in an existing project.
2. Create a clone of entire GIT repository from a
remote server.
 How GIT stores data
• GIT stores the data in terms of “snapshots”.
• The term “snapshots” is used to replace the word
“re-vision” generally used with other VCS system.
• Whenever we “commit” in the GIT, it stores the
data in terms of “set of snapshots”.
• It can be imagined as “snapshots” of each files is
taken and stored in GIT repository.
 Project - MySpecialTea
MySpecialTea

Ingredients IngredientsCost Recipe

File6
File1 File2 File3

File5 File5
File4
 Tracking an existing project using GIT
• In order to track files of an existing project we
need to initialize a GIT repository inside the
project.
• For this go to the project directory using GIT Bash
and run following command:
<directory path> git init
• If the above command is successful, then a empty
GIT repository is created inside the specified path.
(as a hidden holder)
• This empty GIT repository is just a GIT skeleton and
none of the files are tracked yet.
• But how to track files of any project????
 Adding files to “GIT repository”
• For tracking any files we need to add them in GIT
repository and then do a initial “commit”. This is
done by following commands :git add *.txt
 The above command will add all files having .txt
extension
 In order to check the status of files, we can use
following command: git status
> In order to commit already track files following
command is used : git commit –m “my first commit”
 The above command will do a “commit” and needs a
commit statement.
 Without commit statement the process will be
aborted.
 GIT file status life cycle

Git local
repository

Working
directory

Commit
Staging Area

Add
 Changing already tracked files -
Modification
• In order to see any new change in the files which are
already tracked following command is used :
git status
• Lets do a small change in our project :
 We need to double the quantity of tea.
 For this all files under “Ingredients” and
“IngredientCost” will be change.
• Now again run the following command to see the
new status of the files :
git status
 It will show all the files which are changed.
 Adding Modified files - Staging
• Every time we change/modify already tracked
file we need to “add” it again so that it will
ready to “commit”.
• This process is known as “Staging”.
• For staging modified files we have to use “add”
command again :
git add *.txt
> “add” is a multipurpose command which is used
to make your files ready for commit.
 GIT file status life cycle cont.
• There are three important states of GIT files :
1. First one is the working directory where a
programmer do all of his work.
2. Once we use “add” command on working
directory all files are “staged” or ready to
commit. Here the snapshots of all files are
already taken.
3. When we use the “commit” command, only
those snapshots are permanently stored in the
GIT repository which have some “changes”.
 Command To display changes
• In order to display all “changes” done in the
files following command is used:
“git diff”

• But if the files are in staging area, then

following command is used :
“git diff –cached”
 Command display commit logs
• In order to display all previous commit logs
following command is used :
“git log”

• In order to get log only in single line following

command is used :
“git log --oneline”

• If the git logs are too large to show on the screen,

then it will throw us on command line editor. In
order to exit from this editor following key
combination is use :
“ hold shift + zz”