Git vs. SVN

Mein Talk von der DevCon Hamburg in 2011

Transcript

1. Git versus SVN
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
4. Warum Versionierung? • Protokollierung • Archivierung • Wiederherstellung
5. Zentrale Versionierung
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
7. Dezentrale Versionierung
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
9. 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)
10. SVN
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“
13. Eine SVN Timeline
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
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
16. Alleinstellungsmerkmale • Properties auf Datei / Verzeichnisebene • svn:externals um entfernte Repositories transparent „hineinzulinken“
17. Git
18. Wer hat‘s erfunden?
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
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)
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.
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.
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“
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
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“
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
28. Arbeitsschritte
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.
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
31. Workflow Modelle
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
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
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
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
38. Enterprising Git
39. Anforderungen an Git im Unternehmen • Authentifizierung (LDAP, ADS, etc) • Autorisierung (Gruppen, Rollen, Rechte) • Automatisierte Backups • Support • Akzeptanz
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
41. Autorisierung • Gitosis oder Gitorious helfen, man verlagert aber nur die Aufgabe • Keine Mechanismen implementiert • Implementierung per Post-Commit / Post-Push Hooks
42. 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. mueller.work@gmail.com > 1305968206 +0200committer Mario Mueller <mario.mueller.work@gmail.com > 1305968206 +0200data 55Res olved #6, but need some relyability fixing later onfrom :279M 100644 :280 src/Prowl/Connector.php
43. Alternativen
44. Bazaar • Von Canonical (Ubuntu) • in Python geschrieben • Aktivste Plattform: Launchpad • Einfacher in der Handhabe • Gefühlt langsamer als Git
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
46. Vielen Dank für die Aufmersamkeit!
47. Fragen