Dieses Dokument mit 16 Folien ist zugleich eine Präsentation. Starten Sie den Folienmodus mit der Taste A, per Doppelklick oder über Vollbild präsentieren.

Tastenkürzel im Folienmodus

Tastenkürzel
Taste	Funktion
`A` / `Esc`	Folienmodus starten / beenden
`→`, `↓`, `Leertaste`	nächster Schritt oder nächste Folie
`←`, `↑`	zurück
`Bild ↓` / `Bild ↑`	nächste / vorherige Folie ohne Einzelschritte
`Pos1` / `Ende`	erste / letzte Folie
`F`	Vollbild ein/aus
`2`	Präsentation in zweitem Fenster, Sprechernotizen und Vorschau im ersten
`C`	Inhaltsverzeichnis (Folienmodus) / Notizen ein- und ausblenden (Dokument)
`N`	Screenreader liest die Sprechernotizen vor
`?`	Hilfe

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 Konsole (Kommandozeile)
Git mit SourceTree (als Beispiel für eine grafische 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 Torvalds initialisiert
Erste Version in wenigen Tagen
Zur Verwaltung des Linux-Kernels (sehr verteilte Entwicklung)
Sehr hohe Effizienz
Sehr hohe Sicherheit
Wegwerf-Zweige

Versionsstrategien

Lineare Entwicklung

Lineare Historie mit nur einem Branch main: Commits Init, First Chapter und Day one (Tag v0.1), danach Day two, Day three und Day four (Tag v0.2).

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 beteiligt ist, da während des Release-Tests keine Weiterentwicklung für die nächste Version möglich ist.
Hotfixes einer Version sind sehr schwer zu realisieren, da eventuell bereits unvollständige Features für die neue Version da sind.

Main – Develop

Stabiler und Entwicklungszweig

Branches main und develop: Nach dem Commit Init auf main entstehen auf develop First Chapter, Day one und Day two. develop wird in main zusammengeführt (Tag v0.1). Danach folgen Day three und Day four auf develop, die erneut in main zusammengeführt werden (Tag v0.2). Day five folgt auf develop.

Main – Develop – 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 Entwicklungsballast).

Main – Develop – Contra

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

Git-flow

main, develop, feature, release, hotfix

Git-flow mit den Branches main, develop, hotfix/0.2, release/1.0 und feature/one bis feature/three: Der Hotfix zweigt von main ab und wird in main (Tag 0.2) und develop zurückgeführt. Features zweigen von develop ab und werden dort wieder zusammengeführt. Der Release-Branch zweigt von develop ab und wird in main (Tag 1.0) und develop zusammengeführt.

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.
Paralleles Weiterentwickeln 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 grafischen 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

Folienmodus beendet.