1. GIT: (a)Gentle InTroduction Bruno Bossola

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

3. 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

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

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

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

7. Concepts

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

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

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

11. 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 :)

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

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

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

15. Local operations

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

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

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

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

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

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

22. 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

23. 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

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

25. 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

26. 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

27. Remote operations

28. 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

29. 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

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

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

32. 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

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

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

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

36. 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)

37. 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!)

38. 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

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

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

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

42. Enterprise adoption

43. 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

44. 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)

45. 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 :)

46. Questions?

47. Thanks! Twitter: @bbossola Email: bbossola@jugtorino.itbbossola@jugtorino.it