Your SlideShare is downloading. ×
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
The basics of version control
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

The basics of version control

138

Published on

A short talk I delivered on the 14th Nov2009 about version control systems

A short talk I delivered on the 14th Nov2009 about version control systems

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
138
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×