$30 off During Our Annual Pro Sale. View Details »

Git vs. SVN

Git vs. SVN

Mein Talk von der DevCon Hamburg in 2011

Mario Mueller

April 27, 2012
Tweet

More Decks by Mario Mueller

Other Decks in Technology

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
  3. None
  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“
  12. None
  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)
  21. None
  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
  35. None
  36. None
  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