GIT: (a)Gentle InTroduction Bruno Bossola

Agenda About version control Concepts Working locally Remote operations Enterprise adoption Q&A

Hey dude who are ya?? Developer since 1988 XP Coach during 2k Co-founder and coordinator of JUG Torino Java Champion since 2005 Manager at Gitenterprise.com Working as contractor across Europe

About version control Picture courtesy of globalnerdy.com All rights kindly reserved

Centralized SCM CVS SVN Picture courtesy of progit.org. All rights kindly reserved

Distributed SCM Git Mercurial Bazaar Picture courtesy of progit.org. All rights kindly reserved

Concepts

Snapshots, not deltas Nearly every operation is local Integrity is a priority The “three states”

Snapshot, not deltas Deltas are maintained: CVS, SVN, Bazaar Picture courtesy of progit.org. All rights kindly reserved

Snapshot, not deltas Full file is maintained: Git, BitKeeper Picture courtesy of progit.org. All rights kindly reserved

Most operations are local Your local database contains a full copy of the remote(s) Browsing, changing, search happens locally Almost everything doable without network the db is a nice, separate.git folder :)

Integrity is a priority Everything in Git is check-summed –SHA-1 hash –40-character string such as 95b b16bb70ded20626c9c551ccd58 It's impossible to make a change without Git knowing it! Git generally only adds data

The three states modified staged committed all local operations! Picture courtesy of progit.org. All rights kindly reserved

Quick demo! Configuration Initializing a local repository Managing files Looking into history

Local operations

How does it work Git has an internal object database It contains – blob (files) – commit – tree – …and other stuff :)

After a commit... Picture courtesy of progit.org. All rights kindly reserved

After three commits... Picture courtesy of progit.org. All rights kindly reserved

A branch is a pointer Picture courtesy of progit.org. All rights kindly reserved

Creating a branch > git branch testing Picture courtesy of progit.org. All rights kindly reserved

HEAD HEAD: a special pointer so Git knows where you are Picture courtesy of progit.org. All rights kindly reserved

Switching to a branch Git moves HEAD pointer to the branch pointer > git checkout testing Switched to branch 'testing' Picture courtesy of progit.org. All rights kindly reserved

Change a file (on a branch) Git keeps following with HEAD the branch pointer > vi readme.txt > git commit -a -m 'readme file updated' Picture courtesy of progit.org. All rights kindly reserved

Switch to master Git moves back HEAD to point to master > git checkout master Picture courtesy of progit.org. All rights kindly reserved

And change again! > vi readme.txt > git commit -a -m 'readme file now rocks!' Git still keeping separate pointers to the branches Picture courtesy of progit.org. All rights kindly reserved

Time to merge! A new “merge” commit is generated > git merge testing Merge made by recursive. 1 files changed, 1 instions(+), 0 dltions(-) Picture courtesy of progit.org. All rights kindly reserved

Remote operations

What's a remote? You can have multiple remote repos – usually one, “origin” – sometimes one main r/w, other r/o, – rarely multiple Collaborating means pushing and pulling data from the remote repos

Using a remote: clone Move into an empty folder... – Different protocols are available git (native) http(s) ssh You get a full copy of the repository > git clone

(less usual) Add a remote Move into an existing git folder... Mostly used when working with multiple repositories > git remote add

Initial clone Picture courtesy of progit.org. All rights kindly reserved

How do it syncs? “master” is tracked automatically “fetch” command will download all the updates from the remote db – “merge” to merge the branches – “rebase” (let's see this later) “pull” is a shortcut for fetch + merge

I do some work... Picture courtesy of progit.org. All rights kindly reserved

Someone else pushes! Picture courtesy of progit.org. All rights kindly reserved

Synchronize with fetch Picture courtesy of progit.org. All rights kindly reserved

What next? Fetch is just fetching all the data, nothing changes To update your master copy to the remote you may: – Merge – Rebase You can have done a pull (fetch + merge)

Merge! Git uses an automatic three-ways merge algorithm very efficient :) Most of the time it's a piece of cake Any conflict not resolved automarically must be resolved... by you (as usual!)

Rebase! First removes from the target branch the diverging commits Then adds all the changes committed on the source other branch Then adds your commits on top

Rebase! After a rebase,,, Picture courtesy of progit.org. All rights kindly reserved

Rebase! No differences in result Much cleaner history Branches are then easy to integrate to the master

Quick demo! Cloning a repo Fetching from a remote Merging and rebasing

Enterprise adoption

Issues in the enterprise? No security out of the box – secure protocols are based on OS services – no way to restrict the access to a repository – no way to lock a branch – no audit – you can commit in behalf of someone else

More issues in the enterprise! No easy setup for users and groups administration is a pain (again based on the OS services) Only basic repository visualization (and nothing on the remote)

Solutions? use a predefined solution on top of a *nix environment – gitolite (requires *nix os) – gitosis (requires *nix os) – gerrit (not 100% git, but works well) get an industrialized service/solution – gitenterprise (yeah, the shameless plug, finally!) – Github-fi (guess what? now called github enterprise) – …not much more here :)

Questions?

Thanks!