Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (13)
Similaire à Git How Does That Work Then
Similaire à Git How Does That Work Then (20)
Dernier
Dernier (20)
Git How Does That Work Then
- 1. VCS “Initial commit” David Greaves / lbt
- 2. DVCS git
- 3. complex apply archive bisect blame branch bundle checkout cherry-pick commit config dch describe diff difftool fetch filter-branch format-patch fsck gui help imap-send init log merge pull push rebase relink remote repack request-pull reset revert rm show-branch stage stash status svn submodule tag whatchanged add add am annotate apply archive bisect blame branch buildpackage bundle checkout cherry cherry-pick citool clean clone commit config dch describe diff difftool fetch filter-branch format-patch fsck gc get-tar-commit-id grep gui help imap-send import-dsc import-dscs import-orig init instaweb log merge mergetool mv name-rev pull push rebase relink remote repack request-pull reset revert rm send-email shortlog show show-branch stage stash status submodule svn tag whatchanged
- 4. simple checkout commit diff fetch init log merge status tag add
- 12. Key Benefits Super easy branches Fast Always available Very compact Team player Flexible usage Easy to use gitk Gitorious
Notes de l'éditeur
- 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