Going to assume you all know a little about version control systems... So, the ability to save the history of changes so you can go back to see what changed over time Historically vcs is done on centralised servers shared by a development team (even a team of 1) Used for code – but also for docs, websites, configurations and other things too So we're moving on to DVCS – distributed version control And whilst there are many DVCS systems out there my focus is going to be on git
Many people still used to centralised SVN/CVS-like systems That has a simple model put it in a central shared service Everyone reads and writes there maybe use some exclusive locks; Of course you can't work if you can't connect Duh! How can you commit a change or get another branch? These limitations got itchy... git and others are current State of the art. Things like git have a reputation for being complex. There is definitely a lot there...
but a lot of work has been done on making sure that being powerful
does not force us to be complex In this talk I only have time to introduce a few concepts I hope to encourage attendance at Johan's talk straight after the break There's a follow-up workshop (if you're not listening to Carsten talk about Mer) Workshop we'll go into more detail about git and how we use it in Mer; Next: VCS
We're wondering what is a D VCS? We said we use a VCS to track our development work Provides a history of changes Use branches to keep related changes together until they're stable (eg adding a gesture to let you select a widget) Talk about this in workshop If we have a team we may have a shared codebase. As a project matures we may have a stable release and go back to it to provide bug/security fixes We can do all this So what's missing? What does a D VCS bring?
Think of DVCS as being the equivalent of peer-2-peer There is no one master forced on you – you can decide which repo is master for which task Of course you need to be organised and decide who to trust: Kernel : Linus, or Alan Cox .... or lbt/Stskeeps for the N8x0, SmartQ or Marvell devices Capable of working offline (actually they only work offline) Then you exchange 'patches' with peers Typically you'll send your changes to a public server holding a “clone” of your repository and tell people to pull from there (garage or gitorious) You can just make your dev box a server You can push to a shared central server Any of the above Next: On my own
So this power really does help you manage your own development work Rapid branching, browsing history You're ready for when people want to join your project Next: Team
Same deal – git supports a variety of workflows. It's up to your team which you use: Centralised 'open' repo : shared responsibility amongst the devs (all have commit rights) Someone managing integration testing before commits A team of integration managers for different functional areas. Next: Lets dive into some branching. This is how we use git in Mer
Issue is we need to manage patches against our upstream And we want to make life easy for our downstream. That means keeping the packaging and the code separate. Shows how we have branches for upstream, our code, our package All features or bug fixes are broken out to additional branches; 1 branch per feature or fix. The main difference is that features are not likely to go upstream whilst fixes are. This is very similar to quilt. Next: Upstream release
Here we see development of local patches and merging with an upstream release Consider if there's a linux app you are porting to the device – this is how that looks Next: Maintenance
A view on how you may create a maintenance branch to support eg security patches Next: Summary Benefits
Switch branches almost instantly – makes branches truly useful Checkout is superfast No need to be connected Excellent efficiency Any workflow you like Easy to use – gtk is superb Web tools like Gitorious really make sharing sane Next : Wrap up
VCS – Version Control System - Tracks work Branches – flit about; fix a bug; add a feature Central VCS – share with a team Mature – want to go back to a 'stable' version to fix bugs? Easy. Distributed VCS? What does that bring?
Everyone has their own VCS 'server' – repository You can work totally offline Capable of fetching changes from other people's repos Usually one person has the master repo for a project and they pull changes Any group of people can exchange code-changes between themselves