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
Slide 7
Slide 7 text
Dezentrale Versionierung
Slide 8
Slide 8 text
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
Slide 9
Slide 9 text
VCS Survey (von M. Fowler)
Approval in %
● 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)
Slide 10
Slide 10 text
SVN
Slide 11
Slide 11 text
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“
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 text
Eine SVN Timeline
Slide 14
Slide 14 text
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
Slide 15
Slide 15 text
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
Slide 16
Slide 16 text
Alleinstellungsmerkmale
● Properties auf Datei / Verzeichnisebene
● svn:externals um entfernte Repositories
transparent „hineinzulinken“
Slide 17
Slide 17 text
Git
Slide 18
Slide 18 text
Wer hat‘s erfunden?
Slide 19
Slide 19 text
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
Slide 20
Slide 20 text
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)
Slide 21
Slide 21 text
No content
Slide 22
Slide 22 text
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.
Slide 23
Slide 23 text
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.
Slide 24
Slide 24 text
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“
Slide 25
Slide 25 text
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
Slide 26
Slide 26 text
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“
Slide 27
Slide 27 text
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
Slide 28
Slide 28 text
Arbeitsschritte
Slide 29
Slide 29 text
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.
Slide 30
Slide 30 text
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
Slide 31
Slide 31 text
Workflow Modelle
Slide 32
Slide 32 text
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
Slide 33
Slide 33 text
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
Slide 34
Slide 34 text
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
Slide 35
Slide 35 text
No content
Slide 36
Slide 36 text
No content
Slide 37
Slide 37 text
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
Slide 38
Slide 38 text
Enterprising Git
Slide 39
Slide 39 text
Anforderungen an Git im
Unternehmen
● Authentifizierung (LDAP, ADS, etc)
● Autorisierung (Gruppen, Rollen, Rechte)
● Automatisierte Backups
● Support
● Akzeptanz
Slide 40
Slide 40 text
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
Slide 41
Slide 41 text
Autorisierung
● Gitosis oder Gitorious helfen, man verlagert aber nur die Aufgabe
● Keine Mechanismen implementiert
● Implementierung per Post-Commit / Post-Push Hooks
Slide 42
Slide 42 text
Backups
● Option 1:
Einfach kopieren
● Option 2:
git fast-export --all
mmue-mbp:ProwlPHP mario$ git fast-export --all | less
commit refs/heads/mastermark :281author Mario Mueller < mario.
[email protected] > 1305968206 +0200committer Mario Mueller
1305968206 +0200data 55Res olved #6,
but need some relyability fixing later onfrom :279M 100644 :280
src/Prowl/Connector.php
Slide 43
Slide 43 text
Alternativen
Slide 44
Slide 44 text
Bazaar
● Von Canonical (Ubuntu)
● in Python geschrieben
● Aktivste Plattform: Launchpad
● Einfacher in der Handhabe
● Gefühlt langsamer als Git
Slide 45
Slide 45 text
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