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
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)
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“
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
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
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)
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“
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
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
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
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
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
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