The basics of version control

Barcamp Bradford 2009Matt Fielding | Creative Director | Panoetic Ltd

and how I learnt to love making commits and merges

The basics of Version Control

WEBSITE DESIGN & DEVELOPMENT

®

PANOETIC


Concurrent Editing of Files

Common goals in web development

Revisions / History and Accountability

Manageable 1-way workflow

Separate development versions

4 Goalsu

v

w

x


When did something get changed?

and Accountability

So a file or site has been changed....

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

Why did something get changed?

Who changed it? (or broke it)

Revisions/History

gg

g


Adam is tasked with updating copy and graphics on page headers

an example

Client wants changes to his website.

Now, 2 copies exist, neither is fully up to date. Cue screaming as 1 person overwrites the changes of the other.

Bob is tasked with updating copy and graphics on page footers

Both take a copy of the site to work on, and do their updates.

Concurrent editingu v w

x


The end goal of any site is to get it live

1-way workflow

Breaking the site leads to downtime and errors

Changes direct to a live site are BAD!

Keeping a track of who has what version is impossible

Even a simple typo fix can lead to problems and annoyed clients.

gg

g


Development VersionsSeparate

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

Problems

Editing the “live” version puts it out of sync with the version developers are expanding.

Editing the development version means untested code may go live too early.

g

g


Central store holding the history and files for a given project.

Usually stored online to allow access from

various locations.

To work on a project, you “checkout” a

copy of a version of a branch, and the files

you get are your local “working tree”. The repo is unaffected

until you commit your changes

of Version Control Systems

Repository Checkout

Branch

Trunk:

A separate version of a project with its own

history.

Main development “branch” of a project”

Terminology


Send your changes to the repository for other people to use.

A version of the project in a specific

branch after a commit. These can also usually

be “tagged” with meaningful names, eg

Test Version 3

of Version Control Systems

Commit Revision

Merge

Conflict

Combine 2 or more files or branches together

When the changes in 2 versions of a file or

branch would overwrite each other if merged.

Terminology Continued


Most VCS work with some form of central repository.

Repository Model

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

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

u

v

w


continuedRepository Model y

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

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


visuallyRepository Model

server

branchpull

mergecommit

Main Branch local Branch


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 a conflict, and depending on the VCS will display the sections of the file that have the problem

The committer can then decide which code to keep and “resolve” the conflict.

Conflictsand how to resolve them

>


Every time someone commits new changes to the repository:

History

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

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”

u

v

and Accountability


Every time someone commits new changes to the repository:

History

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

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

w

x

and Accountability


Commit Early, Commit Often

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

Best Practices

Keeps the history easy to follow

Makes reverting a mistake easier

Avoids large merge conflicts

Makes people more targeted in their work

gg

g

g


A site can be branched as a live release.

Going Live

The site can then continue to be developed in trunk.

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

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

g

g

g


DevelopmentTrunk

New BranchRelease 1.0

Bugfix - 1.01

Bugfix - 1.02

New BranchRelease 2.0

New Feature 1

New Feature 2

Latest ChangesMerged In

Branch

Branch

Merge

Commit

Commit

Commit Commit

Commit

Simple Example


Some of the common VCS in use

CVSSVN

GIT Bazaar

Common VCS’Concurrent Versions System

Subversion

Distributed revision control

and


Resources

Bazaar - http://bazaar-vcs.org/en/

Subversion - http://subversion.tigris.org/

Git - http://git-scm.com/

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


Questions?


WEBSITE DESIGN & DEVELOPMENT

®

PANOETIC

http://panoetic.com

http://mattfielding.net

http://www.twitter.com/panoetic

http://www.twitter.com/mattfielding

Matt Fielding

Date post:	27-Jun-2015
Category:	Technology
Upload:	matt-fielding
View:	166 times
Download:	1 times

The basics of version control

Technology