Dezentrale Versionsverwaltung Git

Dipl.-Ing. (FH) Eugen Richter

Git: Themen

  • Warum Versionierung?
  • Geschichte der Versionsverwaltung (allgemein)
  • Geschichte von Git (im besonderen)
  • Übersicht über Versionierungsstrategien
  • Git auf der Console (Kommandozeile)
  • Git mit SourceTree (als Beispiel für eine graphische Oberfläche)

Warum Versionierung?

  • Datensicherung
  • Älterer Zustand
  • Parallele-Arbeit an mehreren Versionen
  • Parallele-Arbeit mit mehreren Personen

Geschichte der Versionierung

  • Zeitstempel-Ordner
  • Dateiversionierung
  • Zentral
  • Verteilt

Geschichte von git

  • 2005 von Linus Torwalds initialisiert
  • Erste Version in wenigen Tagen
  • Zur Verwaltung von Linux Kernel (sehr verteilte Entwicklung)
  • Sehr hohe Effizienz
  • Sehr hohe Sicherheit
  • Wegwerf-Zweige

Versionsstrategien

Lineare Entwicklung

Git nur mit main Branch

Ein Branch - Pro

  • Sehr einfache Benutzung
  • Kein Merge zwischen unterschiedlichen Zweigen notwendig
  • Sehr gut für den Einstieg in die Versionsverwaltung geeignet
  • Sehr gut für Dokument-Versionierung (Bücher, Artikel, Manuskripte usw.)

Ein Branch - Contra

  • Schwer zu handhaben, wenn mehr als nur ein Entwickler beteilig ist, da während des Release-Tests keine Weiterentwicklung für nächste Version möglich ist.
  • Hotfixes einer Version sind sehr schwer zu realisieren, da eventuell bereits unvollständige Features für neue Version da sind.

Main - Develop

Stabliler und Entwicklungszweig

Git mit main und develop Branches

Main - Devlop - Pro

  • Bietet besseren Überblick über ausgelieferte / veröffentlichte Projektstände und belässt die Flexibilität bei der täglichen Arbeit.
  • Schneller Zugriff auf benannte Stände, da diese nur im Master-Zweig vertreten sind (ohne Entwicklungsbalast).

Main - Develop - Contra

  • Schwer zu handhaben, wenn mehr als nur ein Entwickler beteilig ist, da während des Release-Tests keine Weiterentwicklung für nächste Version möglich ist.
  • Hotfixes einer Version sind sehr schwer zu realisieren, da eventuell bereits unvollständige Features für neue Version da sind.

Git-flow

main, develop, feature, release, hotfix

Git Flow Branches

Git Flow – Pro

  • Arbeiten im Team ohne Beeinträchtigungen möglich, da Aufgaben in eigenen Zweigen erledigt werden.
  • Saubere Implementierung der Hotfixes für Release-Versionen ohne Beeinträchtigung der Entwicklung möglich.
  • Paralelles Weiterentwicklen der nächsten Version und vorbereiten (testen) der aktuellen durch Release-Zweige möglich.
  • Auslieferung von Hotfixes in sehr kurzer Zeit möglich, da keine Rücksicht auf den Entwicklungsstand genommen werden muss.

Git Flow – Contra

  • Komplexere Handhabung als beide vorhergehenden Strategien.
  • Momentan wird nur von wenigen graphischen Tools (z.B.: SourceTree unter OS X) direkt unterstützt.
  • Erfordert Disziplin beim Entwickeln, da für jede Aufgabe ein neuer Zweig aufgemacht werden muss.
  • Nicht geeignet, wenn mehrere Release-Versionen über lange Zeiträume parallel gepflegt werden müssen.

Weitere Strategien

  • Forking
  • Pull Request
  • GitHub Flow

Workshop