Version control

Version Control Systems
• Advantages • Types • CVCS • DVCS • Terminology • Best practices • GIT Cheatsheet

§ Version control § Custom tailored dev ! release strategy § "ogging and #eature development trac$ing § Branching ! tagging § Sharing ! code revie% § Encourages thro%ing a%ay code § Automatic &implicit' (ac$ups ) unlimited Ctrl*+

Git &C. -l' ) "inu/ $ernel &"inus Torvalds' Ba0aar &-y' ) Arch "inu/ &Canonical' GN1 Arch &C' ) GN1 -ro2ect &community' "i(reSource ) 3anagement server &IN4IA' SV5 &-l' ) Distri(uted SVN &community' 3ercurial &-y. C' ) 6pen source &G-"v7' #or$ o# Bit5eeper 1sers8 Audacious. Dovecot. "u/4ender. 3o0illa. 3utt. Ngin9. Net(eans. 6pen:D5. 6SSEC. -idgin. -ython. Sym(ian6S. No$ia3aps. Tryton. ;<C

CVS=6penCVS ) 6pen source &G-"' Autodes$ Vault ) AutoCAD &Autodes$' SourceAny%here ) Dynamso#t StarTeam ) 3icro >ocus &e/ Borland' Team >oundation Server ) 3icroso#t 4ational TeamConcert. 4ational ClearCase ) IB3 SVN ) 6pen source &Apache >oundation' 1sers8 AS>. De(ian. Sam(a. 3ono. -uTT,. C1-S. I4SSI. ">S. T4AC. GN1 Enterprise. Ethereal. Net#ilter. T;i$i

Centrali0ed VCS
CVCS uses a client)server architecture8 a server stores the current version&s' o# a pro2ect and its history. and clients connect to the server in order to ?chec$ out? a complete copy o# the pro2ect. %or$ on this copy and then later ?chec$ in? their changes@ Typically. the client and server connect over a "AN or over the Internet@ -ros • Each developer %ill edit his o%n A%or$ing copyB o# the pro2ect and send &or checking in' the di##s to the server@ • The server only accepts changes made to the most recent version o# a #ile@ • Single repository. %hich is de#initely the only one@ -ro(lems8 • At each commit. the server %rites a user supplied description line. the date and the authorCs name to its log #iles. %hich is (ranch speci#ic &the logs are lost %hen merging #rom (ranch to trun$ or another (ranch'@ • Slo%. all operations are done online@ • Di##icult (ranch and merge handling@

Centrali0ed VCS

Centrali0ed VCS

Distri(uted VCS
Distri(uted revision control ta$es a peer to peer approach to version control@ 4ather than a single. central repository on %hich clients synchroni0e. each peerCs %or$ing copy o# the code(ase is a complete repository@ Distri(uted revision control synchroni0es repositories (y e/changing patches #rom peer to peer@ -ros8 • Each %or$ing copy e##ectively #unctions as a remote (ac$up o# the code(ase and o# its change history@ • Common operations &such as commits. vie%ing history. and reverting changes' are light speed #ast. (ecause there is no need to communicate %ith a central server@ • Net%or$ is not involved #or common operations@ • Numerous di##erent development models are possi(le@ -ro(lems8 • Initial cloning o# a repository is slo%er compared to centrali0ed chec$out. (ecause all (ranches and revision history are copied@ • "ac$ o# loc$ing mechanisms that is part o# most centrali0ed VCS and still plays an important role %hen it comes to non mergea(le (inary #iles such as graphic assets@

Distri(uted VCS

• repo, repository8 the o(2ect data(ase %ere the history and con#iguration is stored@ 3ay • • • • • • • • • •

contain several (ranches. o#ten it contains a %or$tree too@ index, staging area: a CcacheC (et%een the %or$tree and devDs repository@ ,ou can add changes to the inde/ and (uild your ne/t commit step (y step@ ;hen your inde/ content is to your li$es you can create a commit #rom it@ clone: clone o# a repository &?2ust another repository?' or the act o# doing so &?to clone a repository?' commit: state o# a pro2ect at a certain time@ Contains a pointer to its parent commit &in case o# a merge8 multiple parents' and a pointer to the directory structure at this point in time@ branch: A di##erent line o# development@ A (ranch in GIT is 2ust a ?la(el? %hich points to a commit@ ,ou can get the #ull history through the parent pointers@ A (ranch (y de#ault is only local to your repository@ upstream: A#ter cloning a repository you o#ten call that ?original? repository ?upstream?@ In GIT itCs aliased to origin a head: The top commit o# a (ranch &commit the la(el points to' HEAD: A sym(olic name to descri(e the currently chec$ed out commit@ 6#ten the topmost commit version: 3ight (e the same as a commit@ Could also mean a released version o# your pro2ect@ tag: A descriptive name given to one o# your commits &or trees. or (lo(s'@ Can also contain a message &eg@ changelog'@ Tags can (e cryptographically signed %ith G-G@ patch: A commit e/ported to te/t #ormat %hich can (e sent (y email and applied (y other users@ Contains the original author. commit message and #ile di##erences@

Best -ractices
• 1se the command line. itDs easier in long term • Branch out. commit o#ten. merge o#ten • Small patch li$e commits • E/plicit commit messages • Commit logical change sets • >ind %hatDs (est #or your pro2ect8
ØThe Never Branch system ØThe Al%ays Branch system ØThe Branch ;hen Needed system

• The 4ule8 trun$=master must compile and pass regression

tests at all times@ Committers %ho violate this rule are pu(licly humiliated@