Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
The basics of version control
1. 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
2. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
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
3. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
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.
4. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
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.
5. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
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.
6. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
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.
7. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
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
8. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
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
9. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
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!
10. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
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.
11. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
Repository Model
visually
branch
pull
commit merge
server
Main Branch local Branch
12. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
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
13. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
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”
14. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
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.
15. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
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
16. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
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.
17. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
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
18. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
Common VCS’
Some of the common VCS in use
CVS Concurrent Versions System
SVN Subversion
Distributed revision control
GIT and Bazaar
19. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
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/
20. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
Questions?
21. Matt Fielding | Creative Director | Panoetic Ltd Barcamp Bradford 2009
Matt Fielding
http://mattfielding.net
http://www.twitter.com/mattfielding
PANOETIC
®
WEBSITE DESIGN & DEVELOPMENT
http://panoetic.com
http://www.twitter.com/panoetic