Version Control G52GRP Guest Lecture 2012

Version Control Branches and what came next Matthew Walton BSc (Hons) Computer Science, University of Nottingham 2003 Junior Software Engineer, CacheLogic, 2003-2005 Postgraduate Research Student, University of Nottingham, 2005-2007 Senior Software Engineer, Thomson Reuters, 2007-2011 Systems Developer, EvoEnergy, 2011-present Developer, DutySheet, 2012-present There are many version control systems. The fundamental thing they all share is tracking the state of a directory tree over time. Where they usually differ is in how they deal with multiple contributors and branching. Branching Branching splits a repository into parallel streams. Contributors can commit freely to both streams. Changes from one branch can be merged into the other. trunk branch Types of branch 'Trunk'/'Master' - default branch, usually where most development work happens 'Feature branch' - develop a big, disruptive new feature without disturbing the rest of the team 'Release branch' - branch when you release a new version of your software. Provides a base for bugfix releases and minor updates Merging 'Merging' is the process of taking changes from one branch and applying them to another. Feature branches usually have all their changes merged into trunk once the feature is complete. Bug fixes on release branches are often merged into trunk if trunk exhibits the same bug. trunk feature A feature B release 1.0.0 feature C release 1.0.1 Branching in Subversion Subversion allows branches and merges between them A branch is a logical copy of another branch at a particular revision or tag 'svn branch' creates new branches 'svn checkout' is given a branch name Branching in Subversion Subversion branches are fairly clunky You have to make a new checkout to work with another branch Subversion's merging and tracking of merges doesn't stand up very well in complex repositories with lots of developers introducing... DVCS Distributed Version Control Systems DVCS DVCS systems abandon the concept of a central repository Instead, each checkout is actually a clone of the repository and contains its entire history and all branches DVCS Each developer makes commits to their local repository From time to time, developers can pull commits from their colleagues' repositories into their own DVCS In practice, it often works better to have a central repository that everyone pushes to and pulls from Because merging between repositories is how changes are shared, a DVCS has to be extremely good at it Git One of the most popular distributed systems today is Git Git is open source and was originally developed by Linus Torvalds to manage the Linux kernel development process Git is quite odd, but extremely powerful Git tags The tag 'master' represents the latest commit in what Subversion calls 'trunk' Other branches have tags pointing to their own most recent commits Users can create their own tags Git workflow git clone git://git.server.com/myproject.git cd myproject git checkout -b feature-a vim src/main.cc git add src/main.cc git commit -m "New feature A" git checkout master git merge feature-a git push origin master master feature-a Branching models No matter what VCS you use you need a policy for branch management Sometimes it's less important what that policy is than the simple fact of having one http://nvie.com/posts/a-successful-git-branching-model/ Resources http://git-scm.com git website (down at time of writing) http://nvie.com/posts/a-successful-git-branching-model/ extensive explanation of one branching model http://subversion.apache.org Subversion website http://svnbook.red-bean.com/ The Subversion book (free to read online) Remotes You can track as many remote repositories as you like Most commonly you only have one, called 'origin' Origin's master branch is called origin/master Compatibility Git comes with support for Subversion repositories 'git svn' offers a set of commands which allow you to set up a Subversion repository as a remote branch Git can push and pull to it Git everything is about commits a commit represents the state of the tree at a particular point in time commits are identified by hashes of their metadata git metadata is verifiable by recomputing these hashes commits can have multiple parents a multi-parent commit represents a merge between branches developers work on clones of the repository a clone contains the origin repository's entire history and all branches each clone can be thought of as an implicit branch other repositories are represented by 'remote tracking' branches