Meine Slides von der DevCon 2011, eine abgewandelte From der Slides von der PHPUG.

1. 1
Git versus SVN

2. 2
Wer bin ich?
Mario Müller (@xenji)
TWT Interactive GmbH - Düsseldorf
Java, PHP, Python, Groovy
FirstSpirit, JEE, Zend Framework, Oxid
NoSQL FTW!
Mac-Head & Linux Enthusiast
Github: http://github.com/xenji

3. 3

4. 4
Warum Versionierung?

5. 4
Warum Versionierung?
Protokollierung

6. 4
Warum Versionierung?
Protokollierung
Archivierung

7. 4
Warum Versionierung?
Protokollierung
Archivierung
Wiederherstellung

8. 5
Zentrale Versionierung

9. 6
Merkmale

10. 6
Merkmale
Es gibt mehr als eine Realität (ein Server, n Workingcopies)

11. 6
Merkmale
Es gibt mehr als eine Realität (ein Server, n Workingcopies)
Revisionen werden zentral verwaltet, Versionsnummern zentral vergeben

12. 6
Merkmale
Es gibt mehr als eine Realität (ein Server, n Workingcopies)
Revisionen werden zentral verwaltet, Versionsnummern zentral vergeben
Vergleiche sind nur direkt mit dem Server möglich

13. 6
Merkmale
Es gibt mehr als eine Realität (ein Server, n Workingcopies)
Revisionen werden zentral verwaltet, Versionsnummern zentral vergeben
Vergleiche sind nur direkt mit dem Server möglich
Häufig wird ein Delta-basiertes Speicherverfahren verwendet, so bleiben
die zu übertragenden Mengen gering

14. 6
Merkmale
Es gibt mehr als eine Realität (ein Server, n Workingcopies)
Revisionen werden zentral verwaltet, Versionsnummern zentral vergeben
Vergleiche sind nur direkt mit dem Server möglich
Häufig wird ein Delta-basiertes Speicherverfahren verwendet, so bleiben
die zu übertragenden Mengen gering
Die Versionshistorie ist nur auf dem Server verfügbar

15. 6
Merkmale
Es gibt mehr als eine Realität (ein Server, n Workingcopies)
Revisionen werden zentral verwaltet, Versionsnummern zentral vergeben
Vergleiche sind nur direkt mit dem Server möglich
Häufig wird ein Delta-basiertes Speicherverfahren verwendet, so bleiben
die zu übertragenden Mengen gering
Die Versionshistorie ist nur auf dem Server verfügbar
Die Zentralisierung ermöglicht ein Zugriffs- und Rechtemanagement

16. 7
Dezentrale Versionierung

17. 8
Merkmale

18. 8
Merkmale
Es gibt viele, mehrdimensionale Realitäten (Multi-Master, Multi-
Workingcopy)

19. 8
Merkmale
Es gibt viele, mehrdimensionale Realitäten (Multi-Master, Multi-
Workingcopy)
Jede Workingcopy ist ein kompletter Klon mit allen Versionen

20. 8
Merkmale
Es gibt viele, mehrdimensionale Realitäten (Multi-Master, Multi-
Workingcopy)
Jede Workingcopy ist ein kompletter Klon mit allen Versionen
Theoretisch gibt es keinen zentralen Server

21. 8
Merkmale
Es gibt viele, mehrdimensionale Realitäten (Multi-Master, Multi-
Workingcopy)
Jede Workingcopy ist ein kompletter Klon mit allen Versionen
Theoretisch gibt es keinen zentralen Server
Das Repository ist lokal und unabhängig

22. 8
Merkmale
Es gibt viele, mehrdimensionale Realitäten (Multi-Master, Multi-
Workingcopy)
Jede Workingcopy ist ein kompletter Klon mit allen Versionen
Theoretisch gibt es keinen zentralen Server
Das Repository ist lokal und unabhängig
Alle Operationen sind lokal

23. 8
Merkmale
Es gibt viele, mehrdimensionale Realitäten (Multi-Master, Multi-
Workingcopy)
Jede Workingcopy ist ein kompletter Klon mit allen Versionen
Theoretisch gibt es keinen zentralen Server
Das Repository ist lokal und unabhängig
Alle Operationen sind lokal
Es ist ein Mechanismus zur Synchronisierung mit einer entfernten Instanz
vorhanden

24. 9
• Active Responses: The total of responses excluding "No Opinion". (eg for
git: 65 + 19 + 1 + 0)
• Approval %: The sum of best and ok responses divided by active responses,
expressed as a percentage. (eg for git: (65 + 19) / 85)
Approval in %
VCS Survey (von M. Fowler)

25. 9
• Active Responses: The total of responses excluding "No Opinion". (eg for
git: 65 + 19 + 1 + 0)
• Approval %: The sum of best and ok responses divided by active responses,
expressed as a percentage. (eg for git: (65 + 19) / 85)
Approval in %
VCS Survey (von M. Fowler)

26. 10
SVN

27. 11
Geschichte

28. 11
Geschichte
Version 1.0 am 20. Oktober 2000

29. 11
Geschichte
Version 1.0 am 20. Oktober 2000
Enwickelt von CollabNet

30. 11
Geschichte
Version 1.0 am 20. Oktober 2000
Enwickelt von CollabNet
Seit dem 10. Feb. 2010 ein Apache Top-
Level Projekt

31. 11
Geschichte
Version 1.0 am 20. Oktober 2000
Enwickelt von CollabNet
Seit dem 10. Feb. 2010 ein Apache Top-
Level Projekt
Weiterentwicklung vom ebenfalls zentralen
Versionierungstool „CVS“

32. 12
Begriffe

33. 12
Begriffe
Branch
Changeset
Revision
Tag

34. 13
Eine SVN Timeline

35. 14
Vorteile

36. 14
Vorteile
Kostenfrei erhältlich

37. 14
Vorteile
Kostenfrei erhältlich
Erprobt im OpenSource- und Unternehmens-
alltag

38. 14
Vorteile
Kostenfrei erhältlich
Erprobt im OpenSource- und Unternehmens-
alltag
Stetige Entwicklung als Apache Projekt
gesichert

39. 14
Vorteile
Kostenfrei erhältlich
Erprobt im OpenSource- und Unternehmens-
alltag
Stetige Entwicklung als Apache Projekt
gesichert
Hohe Akzeptanz

40. 14
Vorteile
Kostenfrei erhältlich
Erprobt im OpenSource- und Unternehmens-
alltag
Stetige Entwicklung als Apache Projekt
gesichert
Hohe Akzeptanz
Unterstützt von vielen IDEs, Clients und Project
Hosting Anbietern (z. B. SourceForge)

41. 14
Vorteile
Kostenfrei erhältlich
Erprobt im OpenSource- und Unternehmens-
alltag
Stetige Entwicklung als Apache Projekt
gesichert
Hohe Akzeptanz
Unterstützt von vielen IDEs, Clients und Project
Hosting Anbietern (z. B. SourceForge)
Einfache Handhabung

42. 14
Vorteile
Kostenfrei erhältlich
Erprobt im OpenSource- und Unternehmens-
alltag
Stetige Entwicklung als Apache Projekt
gesichert
Hohe Akzeptanz
Unterstützt von vielen IDEs, Clients und Project
Hosting Anbietern (z. B. SourceForge)
Einfache Handhabung
Authc & Authz abbildbar

43. 15
Einschränkungen

44. 15
Einschränkungen
Ohne Server geht nichts

45. 15
Einschränkungen
Ohne Server geht nichts
Es werden nur Deltas verwaltet

46. 15
Einschränkungen
Ohne Server geht nichts
Es werden nur Deltas verwaltet
Automatisches Mergen ist in vielen Fällen
keine schöne Erfahrung

47. 15
Einschränkungen
Ohne Server geht nichts
Es werden nur Deltas verwaltet
Automatisches Mergen ist in vielen Fällen
keine schöne Erfahrung
Jeder Commit muss einzeln gemergt
werden

48. 16
Alleinstellungsmerkmale
Properties auf Datei / Verzeichnisebene
svn:externals um entfernte Repositories
transparent „hineinzulinken“

49. 17
Git

50. 18

51. 18

52. 18
Wer hat‘s erfunden?

53. 19
Linus Torvalds

54. 19
Linus Torvalds
Initiator der Linux - Bewegung

55. 19
Linus Torvalds
Initiator der Linux - Bewegung
Wahrscheinlich der berühmteste
Entwickler der heutigen Zeit

56. 19
Linus Torvalds
Initiator der Linux - Bewegung
Wahrscheinlich der berühmteste
Entwickler der heutigen Zeit
Entwickelt aktiv am Linux Kernel

57. 19
Linus Torvalds
Initiator der Linux - Bewegung
Wahrscheinlich der berühmteste
Entwickler der heutigen Zeit
Entwickelt aktiv am Linux Kernel
Ist Erfinder von Git, jedoch nicht mehr der
Hauptentwickler

58. 20
Geschichte
Gestartet im April 2005 um den damals
verwendeten BitKeeper zu ersetzen
Aktuell in der Version 1.7.x verfügbar
Schnell adaptiert worden (GitHub,
Gitorious)

59. 21
Begriffe

60. 21
Begriffe
Clone
Pull
Staging
Push
Remote

61. 22
Clone
Unter einem „Clone“ versteht man das
Spiegeln einer vollständigen Historie in ein
(lokales) Repository.
Dabei wird jeder Commit, jeder Tag und jeder
Branch mit einbezogen.

62. 23
Remotes
Branches werden in Git in zwei Zuständen
verwaltet. Lokal und Remote. Ein Remote
Branch ist eine Referenz auf einen lokalen
Branch in einem entfernten Repository.
Remotes werden interessant, wenn
mehrere Entwickler am selben Branch
arbeiten und den entwickelten Quellcode
verteilen wollen.

63. 24
Staging
Hinzufügen von Dateien in einen virtuellen
Bereich
Alle Daten im Stage kommen in den
nächsten Commit
Commits sind dadurch auf CLI Ebene
„zusammenbaubar“

64. 25
Push
Übermittelt den Inhalt eines Branches aus
einem lokalen Repository an ein Remote
Repository
Transferiert Commit-By-Commit
Aus Sicht des Remote Repositories sieht
es aus, als hätte die Person lokal
Commit‘ed

65. 26
Pull
„Zieht“ Änderungen aus einem Remote
Repository
Wenn mehrere Branches aus einem
Remote existieren (z. B. nach einem
Clone eines Repositories mit mehreren
Branches), werden diese ebenfalls
„gezogen“
Explizites „ziehen“ ist möglich -> nur
„master“, nur „2.1.0“, nur „testing“

66. 27
Funktionsweise

67. 27
Funktionsweise
Git Repositories bestehen aus drei Komponenten:
Tree Objekte
Commit Objekte
Blobs (Binary Large OBjects)
Jedes Objekt bekommt eine repository-weit eindeutige ID in From einer
SHA-1 Prüfsumme

68. 27
Funktionsweise

69. 28
Arbeitsschritte

70. 29
Vorteile
Schnell, da eine Vielzahl der Operationen
lokal ist
Unabhängig, da kein Server benötigt wird
Sicher, da jeder alles besitzt (= verteiltes
Backup)
Objekt-orientierte Sichtweise auf die
Teilstücke des Versionsbaumes
Vollkommene Freiheit, da jeder sich selbst
organisieren kann.

71. 30
Einschränkungen
Autorisierung per SSH unter Windows nur
per PuTTY - Toolbox
Einsatz unter Windows nur per mingw
Kaum gute GUIs oder IDE Plugins
„Ungemütliche Lernkurve“
Vollkommene Freiheit

72. 31
Workflow Modelle

73. 32
Team Organisation
Es sind verschiedene Ansätze zur
Organisation von Teams entstanden
Viele sind auch in der zentralisierten Welt
vorhanden, aber wenig genutzt
Canonical hat mit der Veröffentlichung von
Bazaar in Verbindung mit Launchpad sehr
gute Arbeit geleistet und mögliche
Workflows dokumentiert (http://
wiki.bazaar.canonical.com/Workflows)
Hier stelle ich 3 Modelle beispielhaft vor

74. 33
Workflow - Ein User
Der „Freelancer - Workflow“
Gut für einzelne Programmierer, die
Weder Zeit
noch Resourcen für das Setup eines SVN
Servers haben
Schlecht, wenn man kein Backup hat und
die Festplatte / das Speichermedium
verliert

75. 34
Workflow - kleines Team
Es gibt ein „blessed“ Repository, also ein
zentrales Repository
Jeder klont sich dieses Repository ein mal
Ab dann werden Änderungen per push &
pull verteilt
Sinnvoll für kleine Teams (zwischen 2 und
6 Leuten) mit überschaubaren Commit-
Zahlen

76. 35
Workflow - Integration Manager

77. 36
Workflow - (benevolent) Dictator

78. 37
Workflow Integ. Manager / Dictator
Für große Teams geeignet
Hoher Management-Aufwand
Hohe Parallelisierung
Sehr guter Zustand des Repository
Der Integration Manager lohnt sich ab 10-15 Personen
Das Dictator Modell lohnt sich erst bei 50+ Personen

79. 38
Enterprising Git

80. 39
Anforderungen an Git im Unternehmen
Authentifizierung (LDAP, ADS, etc)
Autorisierung (Gruppen, Rollen, Rechte)
Automatisierte Backups
Support
Akzeptanz

81. 40
Authentifizierung
Ist mit Linux - Bordmitteln anstrengend
Gitosis und Gitorious bieten Hilfe
Integrierte directory-basierte Lösungen sind keine Vorhanden
HTTP Push ermöglicht jedoch Autorisierung per Webserver
Erweiterte Authentifizierung kann man per Hooks hacken

82. 41
Autorisierung
Gitosis oder Gitorious helfen, man verlagert aber nur die Aufgabe
Keine Mechanismen implementiert
Implementierung per Post-Commit / Post-Push Hooks

83. 42
Backups
mmue-mbp:ProwlPHP mario$ git fast-export --all | less
Option 1:
commit refs/heads/master
mark :281 Einfach kopieren
author Mario Mueller <mario.mueller.work@gmail.com> 1305968206 +0200
committer Mario Mueller <mario.mueller.work@gmail.com> 1305968206
+0200
data 55 Option 2:
Resolved #6, but need some relyability fixing later on
from :279 git fast-export --all
M 100644 :280 src/Prowl/Connector.php

84. 43
Alternativen

85. 44
Bazaar
Von Canonical (Ubuntu)
in Python geschrieben
Aktivste Plattform: Launchpad
Einfacher in der Handhabe
Gefühlt langsamer als Git

86. 45
Mercurial
Wir seit Q4 2010 von Atlassian weiter entwickelt
Ist ebenfalls in Python geschrieben
Aktivste Plattform: Bitbucket, Google Code
Ist einfacher als Git, einfacher als Bazaar
Performanter als Bazaar, wenig langsamer als Git

87. 46
Vielen Dank für die
Aufmersamkeit!

88. 47
Fragen