Versionskontrolle. Vortrag im Master-Praktikum MindStreams Sommersemester Michael Fiedler 30.

Transkript

1 Versionskontrolle Vortrag im Master-Praktikum MindStreams Sommersemester 2013 Michael Fiedler 30. April / 33

2 Überblick 1 Versionskontrolle 2 Git 3 GitFlow 4 Zusammenfassung 5 Anhang: mehr zu Git 2 / 33

3 1 Versionskontrolle 2 Git 3 GitFlow 4 Zusammenfassung 5 Anhang: mehr zu Git 3 / 33

4 Warum Versionskontrolle? Protokollierung Wiederherstellung Archivierung Koordinierung verzweigte Entwicklung 4 / 33

5 Entwicklung der Versionskontrollsysteme lokal zentral verteilt RCS (1982) CVS (1990) Subversion (2000) Git (2005) Bitkeeper (2000), Darcs (2003), Mercurial (2005), Bazaar (2005),... 5 / 33

6 Warum verteilt? keine Netzwerkanbindung für Festhalten einer Änderung notwendig Änderungen können privat/lokal bleiben, bis sie reif zur Weitergabe sind neue Arbeitsabläufe möglich, z. B. direkter Austausch zwischen den Entwickler-eigenen repositories 6 / 33

7 Beispiel: zentralisiert 7 / 33

8 Beispiel: integration manager 8 / 33

9 Beispiel: dictator and lieutenants 9 / 33

10 1 Versionskontrolle 2 Git 3 GitFlow 4 Zusammenfassung 5 Anhang: mehr zu Git 10 / 33

11 Kurzüberblick verteiltes Versionskontrollsystem ursprünglich entwickelt für Linux-Projekt inzwischen weite Verbreitung Verbreitung unterstützt durch Projektverwaltungsplattformen wie GitHub und Gitorious 11 / 33

12 Grundlegende Verwendung neues Projekt beginnen: git init vim hello.c # hinzufuegen zum staging-bereich git add hello.c git commit -m "first step towards world domination" Arbeit an bestehendem Projekt git clone ssh://user@git.example.org/helloworld.git cd helloworld vim hello.c git add hello.c git commit -m "fixed bug #42" git push origin master... git pull origin master Übersicht zu weiteren wichtigen Befehlen und Mechanismen im Anhang 12 / 33

13 Fortgeschrittene Konzepte: Wie füge ich ein neues Software-Merkmal hinzu? für jedes neue Merkmal ein neuer Entwicklungszweig (?) Entwicklung in diesem Zweig bis zur Fertigstellung kontinuierliche Integration der im Hauptentwicklungszweig hinzukommenden Änderungen abschließend: Integration in Hauptentwicklungszweig 13 / 33

14 Fortgeschrittene Konzepte: rebase vs. merge zwei Möglichkeiten zur Integration in Hauptentwicklungszweig: rebase und merge Was ist besser? Kernpunkt: Sind die verzweigten Neuentwicklungen öffentlich zugänglich und werden von anderen Personen verwendet? wenn ja: merge besser, sonst verlieren andere Leute ihre Arbeitsbasis wenn nein: rebase besser, da übersichtlicherer Projektgraph (?) Wie Änderungen von Hauptentwicklung in den eigenen Merkmalszweig übernehmen? Projektrichtlinien, die den einen oder anderen Weg fordern? 14 / 33

15 Fortgeschrittene Konzepte: Wie sieht ein guter commit aus? (1) nur eine einzige logische Änderung ein neues Merkmal kann auch über mehreren commits eingeführt werden (vgl. patchsets auf Linux Kernel Mailinglist) Fehlerkorrektur Geschwindigkeitsverbesserung API-Aktualisierung neuer Quelltext, der sie verwendet Vorteile: merge wird einfacher, bessere Übersichtlichkeit,... Projekt sollte immer bauen und alle Tests durchlaufen! Sinn: nachträgliche Identifikation fehlerhafter Quelltextstellen, z. B. mit git-bisect leichter möglich evtl. in Verbindung mit cherry picking von einen Fehler reproduzierenden Tests andere Entwickler bauen auf dem Commit ihren eigenen Code auf und bekämen sonst Probleme/Mehraufwand 15 / 33

16 Fortgeschrittene Konzepte: Wie sieht ein guter commit aus? (2) keine Dateien einchecken, die beim Bauen der Software erzeugt werden (Objektdateien, die ausführbare Programmdatei,... ) sauberer und korrekter Quelltext (keine Fehler, TODOs, Speicherlecks,... ) commit-beschreibung erste Zeile: aussagekräftige Kurzbeschreibung zweite Zeile: leer ab dritter Zeile: ausführlichere Beschreibung 16 / 33

17 Fortgeschrittene Konzepte: Wie sieht ein guter commit aus? (3) projektspezifische Kriterien Signed-off-by, Reported-by, Acked-by usw. (z. B. bei Linux) coding style Tabulator versus Leerzeichen zur Einrückung Leerzeichen am Zeilenende Dokumentation Namenskonventionen Urheberrechtshinweise... Bugtracker-ID auf Mängel kann teilweise mit hooks automatisch geprüft werden 17 / 33

18 1 Versionskontrolle 2 Git 3 GitFlow 4 Zusammenfassung 5 Anhang: mehr zu Git 18 / 33

19 GitFlow Anfang 2010: Blog-Eintrag A successful Git branching model Beschreibung eines Arbeitsablaufs für Git-basierte Projekte Verzweigungsstrategie, Umgang mit Veröffentlichungen zentralisierter Ansatz (für Hauptzweige) Werkzeugunterstützung 19 / 33

20 GitFlow Entwicklungszweige Kategorien von Entwicklungszweigen: je ein Zweig für Entwicklung (develop) Veröffentlichungen (master) mehrere für Einführung neuer Software-Merkmale (feature branches) zur Integration in develop (nur in dezentralen Entwickler-Repositories; kein fast-forward merge, sodass Verzweigung (merge commit) erhalten bleibt) Pflege einzelner Veröffentlichungen (release branches) Korrektur schwerwiegender Fehler (hotfixes) in master und develop -> Abbildung 20 / 33

21 21 / 33

22 GitFlow Werkzeugunterstützung Hilfsskripte als Git-Erweiterung (erhältich auf GitHub) Ziel: Einhaltung eines korrekten Arbeitsablaufs Verwendung abstrakterer git-flow-befehle anstatt der low-level-git-befehle git-flow-init git-flow-feature git-flow-release git-flow-hotfix / 33

23 GitFlow Bewertung Vorteile klar festgelegte Vorgehensweise Unterstützung verteilter Entwicklung, insbesondere durch Trennung der Merkmale in Entwicklung von den fertiggestellten konsistente Vorgehensweise wird bei Verwendung der Werkzeuge sichergestellt Nachteile Werkzeugunterstützung: reguläre Git-Werkzeuge müssen trotzdem beherrscht und verstanden werden, da git-flow-befehle nicht immer erfolgreich sind Einschränkung der Freiheiten, die Git bietet? 23 / 33

24 1 Versionskontrolle 2 Git 3 GitFlow 4 Zusammenfassung 5 Anhang: mehr zu Git 24 / 33

25 Zusammenfassung Versionskontrollsysteme heute: verteilt Git grundlegende Verwendung Verwendung von branches korrekte commits GitFlow: Vor- und Nachteile 25 / 33

26 Fragen? 26 / 33

27 Quellen und weiterführende Informationen (1) Versionsverwaltung Git Wikipedia: Versionsverwaltung (deutsch, englisch) und dort verlinkte Artikel zu den einzelnen Systemen Pro Git auf der offizilellen Website zu Git Linux tree: Documentation/CodingStyle Linux tree: Documentation/SubmittingPatches LKML: Linux Kernel Mailinglist Praktikum Angewandte Systemsoftwaretechnik (Lehrstuhl für Informatik 4 für verteilte Systeme und Betriebssysteme) 27 / 33

28 Quellen und weiterführende Informationen (2) Git (Fortsetzung) git merge vs git rebase: Avoiding Rebase Hell Git merge vs. rebase Stack Overflow: git workflow and rebase vs merge questions GitFlow A successful Git branching model (initialer Blog-Eintrag) Why aren t you using git-flow? (Umgang mit GitFlow-Werkzeugen) GitFlow-Erweiterungen zu Git bei GitHub Git Flow einfaches Arbeiten mit dem perfekten Git Workflow (Einführung zur Verwendung von GitFlow) Branching Is Easy. So? Git-flow Is Not Agile. (Kritik an GitFlow) The problem with git flow (Kritik an GitFlow) 28 / 33

29 1 Versionskontrolle 2 Git 3 GitFlow 4 Zusammenfassung 5 Anhang: mehr zu Git 29 / 33

30 Anhang: weitere hilfreiche Git-Befehle (1) Für Details: manpages konsultieren! git add -p: Hinzufügen von Quelltext zum staging-bereich in kleinerer Granularität als der Dateiebene git rm: unter Versionskontrolle stehende Datei entfernen git mv: unter Versionskontrolle stehende Datei umbenennen/verschieben git status: Bericht über den aktuellen Zustand des repository anzeigen git log [--short -p]: Betrachten der bisherigen commits, auch inkl. diff (Schalter -p) gitk: graphische Oberfläche fürs Betrachten der Versionsgeschichte git diff: Unterschied zwischen verschiedenen Versionen oder der letzten Version und der aktuellen Arbeitskopie anzeigen 30 / 33

31 Anhang: weitere hilfreiche Git-Befehle (2) git fetch: Änderungen von anderem repository abrufen git checkout [zweig -b neuerzweig tree-ish]: Wechseln in einen anderen Entwicklungszweig/-stand oder Erstellen eines neuen Zweigs git grep hello: in den unter Versionskontrolle stehenden Dateien nach der Zeichenkette hello suchen git show: Änderungen einer bestimmten Version anzeigen git merge featurebranch master: Integration der Änderungen von featurebranch in master git pull [--rebase]: Abrufen und Anwenden der Änderungen aus einem anderen repository auf den aktuellen Zweig (git fetch mit anschließendem git merge oder git rebase) 31 / 33

32 Anhang: weitere hilfreiche Git-Befehle (3) git reset [--hard]: Zu einem vorherigen Versionszustand zurückgehen. Achtung: nicht eingecheckte Änderungen gehen verloren! git branch [-a -r -d zweig -D zweig]: Auflisten und Löschen von Zweigen git stash [pop]: bestehende Änderungen an der Arbeitskopie vorübergehend beiseite legen und später wieder herholen git tag: Versionen mit Namen versehen git rebase -i: Neuschreiben, Umsortieren, Ändern der Versionsgeschichte der letzten commits git cherry-pick: Änderungen bestimmter vorhandener commits anwenden git bisect: Suche nach einer Änderung, die einen Fehler eingeführt hat 32 / 33

33 Anhang: Sonstiges zu Git.gitignore: Liste von Dateinamensmustern, die von git ignoriert werden sollen, z. B. bei git status *~ *.swp *.o $HOME/.gitconfig: benutzerspezifische Konfigurationsdatei [user] name = Hans Wurst = dev@hanswurst.de hooks: ausführbare Dateien in.git/hooks, die in bestimmten Situationen ausgeführt werden, z. B. vor/nach einem commit, und durch Beenden mit Fehlerstatus eine Aktion abbrechen können (z. B.: kein commit möglich, wenn Projekt nicht mehr baut) 33 / 33