The basics of version control

Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009

The basics of
Version Control
and how I learnt to love making
commits and merges

PANOETIC
®

WEBSITE DESIGN & DEVELOPMENT


4 Goals
Common goals in web development

u Revisions / History and Accountability
v Concurrent Editing of Files
w Manageable 1-way workflow
x Separate development versions


Revisions/History
and Accountability

So a file or site has been changed....
g When did something get changed?
g Why did something get changed?
g Who changed it? (or broke it)

We can go back before the file was changed
if something has broken.


Concurrent editing
an example

u
Client wants Adam is tasked
v Bob is tasked with
w
changes to his with updating copy and updating copy and
website. graphics on page headers graphics on page footers

x Both take a copy of the site to work on, and do their updates.
Now, 2 copies exist, neither is fully up to date. Cue screaming
as 1 person overwrites the changes of the other.


1-way workflow
The end goal of any site is to get it live
Changes direct to a live site are BAD!

g Breaking the site leads to downtime and errors
g Keeping a track of who has what version is impossible
g Even a simple typo fix can lead to problems and annoyed
clients.


Separate Development
Versions
The client asks for new features whilst also asking for some
typo / bug fixes to the live site.

Problems

g Editing the “live” version puts it out of sync with the
version developers are expanding.
g Editing the development version means untested code may
go live too early.


Terminology
of Version Control Systems

Repository Trunk: Checkout
Central store holding Main development To work on a project,
the history and files “branch” of a project” you “checkout” a
for a given project. copy of a version of a
Usually stored online Branch branch, and the files
to allow access from you get are your local
various locations. A separate version of “working tree”. The
a project with its own repo is unaffected
history. until you commit your
changes


Terminology
of Version Control Systems
Continued

Commit Conflict Revision
Send your changes When the changes in A version of the
to the repository for 2 versions of a file or project in a specific
other people to use. branch would overwrite branch after a commit.
each other if merged. These can also usually
Merge be “tagged” with
meaningful names, eg
Combine 2 or more files Test Version 3
or branches together


Repository Model
u Most VCS work with some form of
central repository.

v Different developers check out
“working copies or branches” from
the repository to work on.

w They do their alterations and TEST
their changes.. No changes should be
commited that don’t work!


Repository Model
continued

y They “commit” their new version
back to the repository, annotating any
changes made.

z Any non-conflicting changes get
merged, any conflicts get flagged and
resolved.


Repository Model
visually

branch
pull
commit merge
server

Main Branch local Branch


Conflicts
and how to resolve them

Conflicts occur when a file being committed to the repository
has been edited in the meantime, and the relevant code seems
to overlap.

In this case the VCS will alert of The committer can then
a conflict, and depending on the > decide which code to keep
VCS will display the sections of and “resolve” the conflict.
the file that have the problem


History
and Accountability

Every time someone commits new
changes to the repository:

u A complete history is kept of all files and
what has been changed.

v A commit message is required, in which the person
committing a change outlines exactly what has
been done. This message is detailed and explains
properly, eg don’t comment “fixed a bug”


History
and Accountability

Every time someone commits new
changes to the repository:

w The history stores when and who made the
changes. (no hiding)

x The history is browsable for any file or folder, and
any version of any file can be “diffed” to see what
changed.


Best Practices
Commit Early, Commit Often

Do a small meaningful job, test it, and commit it.

g Keeps the history easy to follow
g Makes reverting a mistake easier
g Avoids large merge conflicts
g Makes people more targeted in their work


Going Live
A site can be branched as a live release.

g The site can then continue to be developed in trunk.

g Changes can be made to the live “branch” and pushed to
the live server.

g These can then be “merged” into the trunk prior to
new release.


Simple Example
Development Branch New Branch
Trunk Release 1.0

Commit Commit

New Feature 1 Bugfix - 1.01
Commit Commit

New Feature 2 Bugfix - 1.02
Merge
Commit

Latest Changes Branch New Branch
Merged In Release 2.0


Common VCS’
Some of the common VCS in use

CVS Concurrent Versions System
SVN Subversion

Distributed revision control

GIT and Bazaar


Resources
Visual introduction to version control -
http://betterexplained.com/articles/a-visual-guide-to-version-control/

Eric Sink’s guide to version control
http://www.ericsink.com/scm/source_control.html

Bazaar - http://bazaar-vcs.org/en/
Subversion - http://subversion.tigris.org/
Git - http://git-scm.com/


Questions?


Matt Fielding
http://mattfielding.net
http://www.twitter.com/mattfielding

PANOETIC
®

WEBSITE DESIGN & DEVELOPMENT

http://panoetic.com
http://www.twitter.com/panoetic

The basics of version control

More Related Content

What's hot

Similar to The basics of version control

Recently uploaded

The basics of version control