Version Control

System
$git
Prof. B. Thangaraju

1
Why do we need Version Control System (VCS)?
• If you are a software developer and working in a project team, your main job is to develop
code for a specific module in your project. Initially you may develop a code locally in your
system. If your project code is getting bigger and bigger then you should maintain the code
carefully.

• Suppose you are working on a code and after making many changes you realize that you
have really messed up or the current version of your code may have some issues and now
you would like to revert to the last good version of your project. How would you do that?

• if you are not maintaining copies of the various versions of your code then you will be in
trouble. So how do you revert to the previous working version of your project code?

2
Version Control System
• In other scenario, if you are working in a project team and develop a module with a group of
team members, every time you work on the project, you should know exactly what has
already been completed, added, changed and so on. How would you know who made the
changes, to which files were changed. Otherwise, you may end up working on something
that is already been finished.

• Now, how do you share your recent code update to your team members? One way is that
you can compress your code with all the necessary artifacts and send every updates through
email then others can start to work with the module. If a large group of developers share
the code updates through mail then someone should collate all the updates into the whole
project code. This process will become a hectic task and error prone.

• This is an inefficient way to share the code updates to the team. Do we have any better
solution to share the code to others and maintain history of each and every updates in a
systematic way? The solution is Version Control System. 3
Centralized Version Control System
• Version control system is the management of changes to collection of information like
documents, project code.
• It can track collaborative changes to a project, so a developer is aware of the recent changes
in the project code and he can access the most recent version of the project.
• Also developers can view all the past versions of the code and the difference between them.
• There are two major types of version control model namely
– 1. Centralized
– 2. Distributed

The centralized version control system is working as a client-server model. Here we have one
centralized server and a localized repository filesystem that is accessible by a number of
clients. The advantage of this centralized model are simplicity and ease of use. One of the
examples of this model is Subversion. 4
Centralized Version Control System Server

Repository

update update update

Working Working Working Working
Copy Copy Copy Copy

Developer 1 Developer 2 Developer 3 Developer 4

Centralized Version Control System
• Google doc is an example of centralized version control system because google doc only
keeps one file for the word document, and everyone works on that one file. Therefore, all
the changes and modifications will be stored and get reflected on that one common file.

• In Subversion there is only one repository filesystem, usually stored on a network server.
Whenever you want to work on your project, you can connect the central file system
through network connection. So you cannot do any work on your project without a network
connection. If anything happened to the central filesystem you may lose your data and or
history of the changes.

• So the disadvantages are the Subversion is completely dependent on the functionality of a

single server, which can become a bottleneck and may affect the performance due to heavy
network traffic and reliability of backups.

6
 Distributed Version Control System
• Distributed version control systems takes a peer-to-peer approach to version control, as
opposed to the client–server approach of centralized systems.
• In the distributed model, all developers have their own local filesystem, and changes between
file system are implemented locally on their machines. The advantages of this model are faster
access, ability to work offline and does not rely on a single location for backups. Example for
this model are GitHub and Mercurial.
• Git has some advantages over other distributed version control systems like Mercurial.
– git is faster than mercurial for network operations such as downloading and uploading project files to the file
server.
– Git’s approach to branches are more powerful than Mercurial.
– git is more powerful for larger projects.
– Git is one of the most widely-used popular version control system in use today. For example, teams at
Amazon and Microsoft have adopted git as their version control system for many of their projects.
– Git is Open Source and you can create a public or private file system which can be accessible by your project
team. 7
 Remote Repository

Distributed Version Control System

4. push

1. pull

Local Local Local

Repository Repository Repository

commit 3. commit commit

update 2. update update

Developer 2 Developer 1 Developer 3

Git
 Git is invented by Linus Torvalds.
 The latest Linux kernel-4.13 has 60,538 files and over 24 million lines of code.
 Approximately 3,500 new lines of code are added into the Linux kernel source code every
day.
 1,681 developers are involved from 225 companies. New version of the Linux kernel is
released in every quarter.
 To maintain such length code which is being worked upon by thousands of developers there
was a need of a tool which could manage such a length code well and make collaborations
between developers across different places and companies efficient and easy.
 Git is used to maintain Linux kernel. Git makes collaboration as quick and painless as
possible.
 If Git helps to maintain a Linux kernel project of that magnitude operating smoothly, you can
imagine how easy git can make collaboration on your projects. 9
Git Vs Github

• Git is a distributed version control

system, it is a tool to manage your
project source code history.

• Whereas Github is a web based, git

file hosting service which enables us
to showcase/share our projects and
files to others.

10
Git Installation

11
Git Configuration

12
Git demo

13
Java Demo Program

14
Git –Stage 1
When you first make changes to a file, the changes will exist only on your local computer in
your working directory. Git has not yet track the changes or modification to those files. In
other words, these files and its changes are not yet part of your development history or are
not visible to anyone except for you.

15
 Git –Stage 2: add
 git should add any files or changes that you
want to include in your development
history, so git knows which files and
changes that it should track.

 The files that we add to our development

history at this stage goes to something
called the “staging area.”

 Staging area is used to review the files and

files changes that you have made. After
doing your reviews, you can then decide
which changes you want git to
permanently track.
16
Git – Stage 3: commit
Once you’re sure about the staged files, you can make a record of your changes and git will
remember the changes. This is known as a commit. The commit will now become a
permanent part of your development history.

17
Git – Stage 3: commit
• There can be a number of commits for a project or code. Each commit might happen at a
particular timestamp.
• A timeline of commits create a graph.
• Commits create links to other commits, forming a graph of your development history. You
can revert back to your previous commit, see how files changed from one commit to the
next, even fix bugs in any of the commits, and review information such as where and when
changes were made.
• Commits are identified in Git by a unique id.
• Each time a commit is made in Git, that commit is assigned an unique id. Because everything
has unique id , it is impossible to make changes, lose information, or corrupt files without
Git detecting it.

18
Git log
• We will run the command #git log
• This command will show us the entire commit history for the project
• It will show us the commit id, the username and mail id of person who made the changes
and also the date and time when the commit was made
• Now we can see the commit ids, if we want to go back to a previous version or commit we
can use that commit id and run the following command-
• Git checkout <commit id>

19
Git Workflow

Staging/Index Remote
Workspace Local Repository
Area Repository

git add

git commit
git push

git pull

20
https://github.com/

21
Sign up

22
Create a Project as Project1

23
Github url

24
Git remote and git push

git remote add origin <URL>

- This command gathers all the committed files from your local repository and uploads them to our
repository we created on github.
git push -u origin master
- This command will push all our local changes to our online repository that is our repository on Github.
“Git push” tells git that we want to upload our files and development history from the repository on our local
computer to a repository hosted on github
“-u origin master” means that we want to upload the “master” version of our commits to a repository on
25
github called “origin”
Git branches
• A branch is the fundamental means of launching a separate line of development with a
software project. In git, you can create many branches resulting in many different lines of
development within a git repository. The branch management in git is lightweight and
simple to learn.
• Each team in a project can work on a different branch simultaneously. When you are ready
and if you want to merge some specific branches or all the branches with master branch you
can do it easily.
• To start off with, git will automatically create a master copy (or “branch” in git terms) of your
project when you create a repository. This master copy is called the “master” branch.
• If you want to do parallel development with the existing project code, without making any
changes to our master branch then you can create different branches based on your need
and each branch will have the same copy of the master branch project source code.
– For example, you can create different branches for different team members. Or you can create different
branches for the different features that you are adding to the project. 26
Working with Git branches
1. Create branches
2. View the created branches
3. Work concurrently with different branches
4. Merge the different branches with the master branch
5. Delete the created branches.

To create a branch we can use command #git branch branchname

#git branch -this command will show us all the created branches
You can work concurrently with different branches
• If we want to move from one branch to other we can run the command, #git checkout
branchname

27
 Working with Git branches
if we are on our master branch and we want to move to branch1,
we will use the command #git checkout branch1
• This command will change our branch from master to branch 1
• Next we will add comment into the calculator.java code.

• After this we will move to our master branch and check the
log message, which shows a detailed information about our
commit details in an order.

since we are working in branch 1, calculator.java will be added

into the “branch1” branch and cannot be seen from the
“master” branch
• Next we will checkout to Branch2
• Next we will again Add comment into the calculator.java code
• And now we will add and commit the file into the branch2.
28
Merging branches
• Merging different branches into master branch
• Now, we can use the command #git merge
branchname to merge branch1 into the master
and then merge team2 branch into the master
branch.
• #git merge branch1
• #git merge branch 2
• Now if we want to the see the difference
between the lines of code from branc1 and
master we will use the command
• #git diff master..branch1
• This command will highlight the added lines into
the calculator.java file.
29
Deleting Branches
Deleting branches locally
• To delete the created branches, we use command, #git branch -d branch_name

30
Managing Conflict
When a team is working on the same project
on the same files but from different branches
conflicts might arise maybe two people end up
changing the same lines of code in a given file.
Git will be confused about which one of the
conflicting changes it should consider for
merging. And in such cases when there are
merge conflict, the merge will fail, and we
won’t be able to merge one branch into
another branch.
If branch1 and branch2 modified the same line
in the calculator.java program then it will create
conflict when you want to merge the branches
into the master branch.
31
Managing Conflict
• The first merge between master and branch1 is working fine but the second merge with team2 creates
conflict.
• When you open the calculator.java file, we can see the conflict details and you can decide whether you want to
keep both the changes or remove any modifications created by branch2.

32
 Managing Conflict
• To remove a conflict we should use our best
judgments to resolve branch conflicts.

We should use our best judgment to determine

which branch is “correct” and which branch is
“faulty”

• Now removed the HEAD and team2 lines and save

the file and then commit the file to keep
modifications done by team1 and team2.

Then add and commit the calculator.java file into the

master branch.

When you compile and execute the program, it will

be working fine and can see the modifications done
by both branch1 and branch 2
33
 git branch creation and merging

Branch Creation

Branch 2

master(v1)

Branch 1

Branch Merge

Branch 2 Add Features

master(v1) master(v2) master(v3)

merge with master merge with master
Branch 1
Add Features
Git clone –working with remote repo
A clone is a copy of a repository. A clone contains all the objects from the original. Each clone
is an independent and autonomous repository and a symmetric peer of the original.

• git clone <URL> - The command git clone creates a new, local Git repository on your
computer and copies all the files, commit histories, commit messages, branches, and etc.

35
Git clone –working with remote repo
1.

• To verify the new commit in github, refresh your github project1 page and you can see
the new updated calladd.java file. 36
 Remote Repository

git clone

4. push

1. clone

Local
Repository

3. commit

2. update

Developer
Git fork
• If you want to work with someone projects or if I want to collaborate with any open source
projects then I need to go their github web page and fork their project into my github
account.
• For example, in our demo, I will fork OVS project from
https://github.com/openvswitch/openvswitch.github.io
• OVS (Open v Switch) is an open source implementation of a distributed virtual multilayer
switch.
• OVS is to provide a switching stack for hardware virtualization environments, while
supporting multiple protocols and standards used in computer networks.
• In the following page, click fork button

38
Collaborate with OSS Project
1.

39
Collaborate with OSS Project
1.

40
Collaborate with OSS Project
Now I will go to my github account and check the forked repository.

The openvswitch open source project is in my remote repository.

You can do the modifications or add any new changes into the
project after cloning into the local repository and push the
changes into your remote repository.

If you want to contribute back to the openvswitch project, you

can create pull request with propose file change details.

The project maintainer of the openvswitch will decide whether

will accept or reject your change proposal.
41
 Your Remote Repository Other Remote Repository
1. fork

5. push 6. pull request

2. clone

Local
Repository

4. commit

3. update

git fork

Developer
Working with OSS
• open source refers to any
program whose source code is
made available for use or
modification as users or other
developers see fit.
• Open source software is usually
developed as a public
collaboration and made freely
available.
• The logo for open source is
copy left symbol and the license
is GPL (General Public License).
One of the main founders of
open source is Richard
Stallman. 43
Working with OSS
Linux kernel (core part of the Linux OS) is published in open source at kernel.org, many
developers develop their own version of Linux operating system in sourceforge.net. Below is
the some list of Linux distribution.

44
Working with OSS
You can browse the sourceforge.net website and you can view open source projects in
different categories. If you are interested you can also work with any projects or you can
create your own project and collaborate with others.

45
Working with OSS
If you are interested to work with Linux kernel, you can view the Kernel mailing list home
page.

46
 Working with OSS
• You can browse the most used topics in Github, you can find at: https://github.com/topics.
• You can contribute to GitHub’s set of featured topics in the github/explore repository. It
categories different topics of your interest.

Starring a repository shows appreciation to the repository

maintainer for their work.

GitHub's repository rankings depend on the number of stars a

repository has.

You can view all the repositories you have starred in your stars
page. 47
Working with OSS
The stars manage page gives details about how to
managing your stars.

• github as a community where your repositories are

public and it allows other coding enthusiasts to
view your projects and if they are interested they
will also help you to add new features into your
project or fix if there are any issues.
• So anyone who is interested in hiring you for a job
or maybe an internship, you can give them a link to
your github portfolio.
• They can view all the projects you have worked on.
If you are really active on github it will give
potential employers a chance to see your work and
you will get a better chance to get suitable job
opportunities.
48
THANK YOU

49