Version Control System

On a single project, a team of software

engineers work together toward a release
• All team members work on the same code and develop their
respective parts
• An engineer may be responsible for an entire class
• Or just a few methods within a particular class
Files have to be shared among developers on
a team project
• Shared files can be kept in some type of Repository where they can
be accessed and worked on by multiple individuals
Sharing files can lead to big problems…
The problem to avoid:
Harry’s changes are lost

Harry’s local file gets overwritten with

Sally’s latest changes.
1. The Problem

• Maintaining group Projects

• Patches are mostly sent via email
• Difficult to roll back
• Almost impossible to maintain if the number of people working in the
project is large
• Testing new unstable features

• Why do we need Version Control System anyway?

What is version control
• 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.
• Software source code as the files under version control, in reality any type of file on a
computer can be placed under version control.
• If you are a graphic or web designer and want to keep every version of an image or layout
(which you certainly would).
• Version Control System (VCS) allows you to:
• revert files back to a previous state
• revert the entire project back to a previous state
• review changes made over time
• see who last modified something that might be causing a problem
• who introduced an issue and when
• Using a VCS also means that if you screw things up or lose files
• you can generally recover easily
• you get all this for very little overhead.
Local version control system
• Many people’s version-control method of choice is to copy files into
another directory
• 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 VCSs
that had a simple database that kept all the changes to files under
revision control.
Local version control system
• A method for recalling versions
of a codebase
• Keeping a record of changes
• Who did what and when in the
system
• Save yourself when things
inevitably go wrong
Version Control: Why?
Individual
• Back-ups of the project
• Create a “checkpoint” in the project at any stage:
• Fearlessly modify code
• Tagging: Mark certain point in time
• Branching: Release versions and continue development
Team
• Everything in “Individual”
• Allow multiple developer to work on the same codebase
• Merge changes across same files: handle conflicts
• Check who made which change: blame/praise
The Lock-Modify-Unlock solution
Early systems followed this model

Sally must wait until Harry releases the lock,

although she can retrieve a “readonly”
version of the file in the meantime.
Lock-Modify-Unlock only allows a single user
to edit the file at a time

Sally must continually poll the system to

see if the file has been unlocked, or Harry
needs to tell her when he unlocks it.
The Copy-Modify-Merge solution allows
concurrent editing

CVS use this model

Harry adds new Sally adds

methods comments
The Repository recognizes conflicts

Harry is prevented from writing

Conflicting versions of the files are merged

Conflicts are automatically resolved in

many cases using robust merging
algorithms.

However, manual merging is sometimes

necessary and can introduce errors.
Copy-Modify-Merge is generally easy to use
and manage
Users can work in parallel

Most of the time, concurrent changes don’t overlap

• People generally don’t edit exactly the same code simultaneously, so merging
is done automatically in many cases
• Amount of time spent resolving conflicts is nearly always less than the time
that would be spent waiting for a lock to be released
Versions form a line
Versions form a line
VCS States
Version Control: Types
• Centralised Version Control System(VCS)
• Distributed Version Control Systems(VCS)
Centralised Version Control System(VCS)
• Major issue that people encounter is that they need to collaborate
with developers on other systems.
• To deal with this problem, Centralized Version Control Systems
(CVCSs) were developed.
• A single authoritative data source (repository)
• Check-outs and check-ins are done with reference to this central
repository
Centralised Version Control System(VCS)
• Concurrent Version System (CVS)
• Subversion (SVN)
• Advantages
• especially over local VCSs
• everyone knows to a certain degree what everyone else on the project is doing.
• Administrators have fine-grained control over who can do what
• and it’s far easier to administer a CVCS than it is to deal with local databases on every client.
• Disadvantages
• single point of failure that the centralized server
• If that server goes down for an hour, then during that hour nobody can collaborate at all or save
versioned changes
• If the hard disk the central database is on becomes corrupted, and proper backups haven’t been
kept, you lose absolutely everything
• Entire history of the project except whatever single snapshots people happen to have on their
local machines.
• Local VCS systems suffer from this same problem
• whenever you have the entire history of the project in a single place, you risk losing everything.
Distributed Version Control System(VCS)
• No single repository is authoritative
• Data can be checked in and out from any repository
• In a DVCS clients don’t just check out the latest snapshot of the files:
they fully mirror the repository.
• if any server dies, and these systems were collaborating via it
• Client repositories can be copied back up to the server to restore it
• Every checkout is really a full backup of all the data
• Examples
• Git
• Mercurial
• Bazaar
• Darcs
Version Control System using Git
Why version control?
• Makes working in a team easy!
1. Code without interference.
2. Go back to a previous version (iOS 10 anyone?)
3. Integrate code of multiple developer’s easily.
4. Know who did what, when.

• Keep your code secure.

• Version Control Systems (VCS) have seen great improvements over
the past few decades and some are better than others.
• VCS are sometimes known as SCM (Source Code Management) tools
or RCS (Revision Control System).
• One of the most popular VCS tools in use today is called Git.
Git
• A distributed version control system
• Command-Line Tool (accessible with Terminal on the Mac or Git
Bash on Windows)
Life Cycle DVCS
GIT Tool
GIT
• Git was created by Linus Torvalds in 2005 for development of
the Linux kernel, with other kernel developers contributing to
its initial development.
Git file state
Understand git
Understand git
Use case 1: keeping an history
• The life of your software/article is recorded from the beginning
• at any moment you can revert to a previous revision 1

• the history is browse able, you can inspect any revision 2

• when was it done ?
• who wrote it ?
• what was change ?
• why ?
• in which context ?

• all the deleted content remains accessible in the history

Use case 2: working with others

• VC tools help you to:

• share a collection of files with your team

• merge changes done by other users

• ensure that nothing is accidentally overwritten

• know who you must blame when something is broken

Use case 3: branching
• You may have multiple variants of the same software, materialized as
branches, for example:
• a main branch
• a maintenance branch (to provide bugfixes in older releases)
• a development branch (to make disruptive changes)
• a release branch (to freeze code before a new release)

• VC tools will help you to:

• handle multiple branches concurrently
• merge changes from a branch into anotherone
Use case 4: working with external contributors
• VC tools help working with third-party contributors:
• it gives them visibility of what is happening in the project

• it helps them to submit changes (patches) and it helps

you to integrate these patches

• forking the development of a software and merging it back into

mainline3
Use case 5: scaling
• Some metrics4 about the Linux kernel (developed with GIT):
• about 10000 change sets in each new version (every 2 or
3 months)

• 1000+ unique contributors

Some illustrations
Some illustrations
Branching example
Branching example
Branching example

50/ 96
Branching example

50/ 96
Branching example

50/ 96
Branching example

50/ 96
Branching example

50/ 96
Branching example

50/ 96
Version Control GIT Intro Local GIT Branches Remote GIT Server Bazar Extras

Branching example

50/ 96
Version Control GIT Intro Local GIT Branches Remote GIT Server Bazar Extras

Branching example

50/ 96
Version Control GIT Intro Local GIT Branches Remote GIT Server Bazar Extras

Branching example

50/ 96
Version Control GIT Intro Local GIT Branches Remote GIT Server Bazar Extras

Branching example

50/ 96
Version Control GIT Intro Local GIT Branches Remote GIT Server Bazar Extras

Branching example

50/ 96
Version Control GIT Intro Local GIT Branches Remote GIT Server Bazar Extras

Branching example

50/ 96
Version Control GIT Intro Local GIT Branches Remote GIT Server Bazar Extras

Branching example

50/ 96
Version Control GIT Intro Local GIT Branches Remote GIT Server Bazar Extras

Branching example

50/ 96
Version Control GIT Intro Local GIT Branches Remote GIT Server Bazar Extras

Branching example

50/ 96
Version Control GIT Intro Local GIT Branches Remote GIT Server Bazar Extras

Branching example

50/ 96
Version Control GIT Intro Local GIT Branches Remote GIT Server Bazar Extras

Branching example

50/ 96
Version Control GIT Intro Local GIT Branches Remote GIT Server Bazar Extras

Branching example

50/ 96
Version Control GIT Intro Local GIT Branches Remote GIT Server Bazar Extras

Branching example

50/ 96
Version Control GIT Intro Local GIT Branches Remote GIT Server Bazar Extras

Branching example

50/ 96
Version Control GIT Intro Local GIT Branches Remote GIT Server Bazar Extras

Branching example

50/ 96
Version Control GIT Intro Local GIT Branches Remote GIT Server Bazar Extras

Branching example

50/ 96
git Commands
• To create a new git repository
git init
• This command works in an empty directory or in an existing project
directory. It creates a .git subdirectory in that directory where it stores all
of the information about the repository
• On Unix-based systems calling it “.git” makes the directory “invisible”
• If you have a set of changes “staged”, you can commit them to the
repository with the command
git commit
• An editor will open where you can type the log message for the commit
git Commands
• To view the current status of a repo
git status
• This will show what branch you are on, what changes there are in the
working directory, and what changes have been staged
• If you have a modified file or a new directory that you want to “stage”:
git add <fileOrDirName>
• If you want to get rid of a file or directory:
git rm <fileOrDirName>
• If you want to rename a file or directory:
git mv <oldFileOrDirName> <newFileOrDirName>
git Commands
• To see the current branches:
git branch
• To create a new branch
git checkout -b <newBranchName>
• To switch to an existing branch
git checkout <branchName>
• To push commits to a remote repository
git push
• To retrieve commits from a remote repository
git pull
 1. GitLab Basics 3. GitLab Issue Tracker
•GitLab - Create Issue
•GitLab - Introduction
•GitLab - Merge Requests
•GitLab - Installation
•GitLab - Referencing Issues
•GitLab - Git Commands
•GitLab - Milestones
•GitLab - SSH Key Setup
•GitLab - Wiki Pages
•GitLab - Create Project
•GitLab - Fork a Project
•GitLab - Create a Branch 4.GitLab Instance Management
•GitLab - Add a File
•GitLab - Create Backup
•GitLab - Rebase Operation
•GitLab - Restore Backup
•GitLab - Squashing Commits
•GitLab - Import Repository

2. GitLab Users and Groups 5.GitLab Continuous Integration

•GitLab - Adding Users
•GitLab CI - Introduction
•GitLab - Create Groups
•GitLab - CI/CD
•GitLab - Remove Users
•GitLab - CI/CD Variables
•GitLab - User Permissions
•GitLab CI - Permissions
•Configuring GitLab Runners
•
•GitLab CI - Advanced usage of CI
https://www.tutorialspoint.com/gitlab/ •GitLab CI - Cycle Analytics
•GitLab CI - Container Registry