Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Git vs. SVN

Git vs. SVN

Mein Talk von der DevCon Hamburg in 2011

6f676db35d9c4a3b701ca41f266d693c?s=128

Mario Mueller

April 27, 2012
Tweet

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