SE_02_Versionsverwaltung PDF

Kapitel 2: Versionsverwaltung Software-Entwicklung im Team erfordert eine Versionsverwaltung 2.1 Einleitung 2.2 Versionsverwaltung: Grundsätzliche Konzepte 2.3 Zentrale u...

Kapitel 2: Versionsverwaltung Software-Entwicklung im Team erfordert eine Versionsverwaltung 2.1 Einleitung 2.2 Versionsverwaltung: Grundsätzliche Konzepte 2.3 Zentrale und dezentrale Versionsverwaltung 2.4 Versionsverwaltung mit Git Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 1 2.1 Einleitung Entwicklung im Team: Versionsverwaltung Ausgangslage: Softwareentwicklung ist Teamarbeit o Viel (indirekte) Kommunikation nötig o Entwicklungswissen muss dokumentiert werden Software besteht aus vielen Dokumenten o Lastenheft o Pflichtenheft o Analyse- und Designdokumenten o Programmcode o Dokumentation o Handbuch Konsequenzen: Oft bearbeiten verschiedene Personen gleichzeitig (und unabhängig voneinander) das gleiche Dokument Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 2 Entwicklung im Team: Versionsverwaltung Typische Probleme / Fragen: Wo ist die aktuelle Version unserer Software? Was ist die zuletzt lauffähige Version deiner Komponente? Wo ist die Version vom 01. April 2023? o Und welche Dokumente beziehen sich auf diese Version? Welche Version wurde dem Kunden „Nissen“ präsentiert? Welche Dateien gehören zum Release 4.5.6 unseres Systems, welches wir vor 3 Jahren an unsere Kunden ausgeliefert haben? o Wir müssen hier nämlich einen schweren Fehler korrigieren und eine neue Zwischenversion an unsere Kunden ausliefern. Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 3  Entwicklung im Team: Versionsverwaltung Einfache Lösungen: Dateien / Ordner kennzeichnen mit Versionsnummer oder ähnlichem Austausch der Dokumente via USB- Stick / Festplatte Austausch der Dokumente via Mail Netzwerkfestplatte Konventionen und Regeln werden im Team definiert Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 4 Entwicklung im Team: Versionsverwaltung Einfache „Lösungen“ erzeugen neue Problem Konventionen und Regeln werden nicht eingehalten Koordination ist aufwendig und führt zu Verzögerungen Varianten und Konfigurationen werden von Hand verwaltet Versions- und Änderungsfragen nicht bzw. nur schwer zu beantworten Geistige Kapazität wird mit „Kleinkram“ verschwendet Fazit: Konventionen müssen technisch erzwungen/unterstützt werden! Sinnvolle Lösung: o Versionsverwaltungssysteme o Lösen (bei vernünftiger Anwendung) alle genannten Probleme (fast) ohne Zusatzaufwand Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 5 2.2 Versionsverwaltung: Grundsätzliche Konzepte Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 6  Versionsverwaltung: Grundsätzliche Konzepte Versionierung zur Nachvollziehbarkeit aller Änderungen Wichtiger Unterschied zu simpler Netzwerkfestplatte! Versionierung bedeutet: Von den Dateien existieren im Repository mehrere Versionen Nach jeder Änderung entsteht im Repository eine neue Version 2 Möglichkeiten: o Datei-Versionierung: Jede Datei besitzt eigene Versionshistorie o Repository-Versionierung: Vom gesamten Repository entsteht neue Version Jede Version besitzt eine eindeutige Versionsnummer Es entsteht somit eine Versionshistorie, die alle an einer Datei jemals vorgenommenen Änderungen dokumentiert Auf alle (auch die alten) Versionen einer Datei kann zugegriffen werden Löschung einer Datei ist spezielle Änderung o Versionshistorie bleibt erhalten o Alte Versionen sind rekonstruierbar Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 7 Versionsverwaltung: Grundsätzliche Konzepte Konsistenzmechanismen Optimistische Mechanismen (copy-modify-merge) o System erlaubt gleichzeitiges Bearbeiten des Dokuments durch verschiedenen Personen o System erkennt und integriert die Änderungen (Merging) o Evtl. funktioniert das nicht automatisch; dann muss der Konflikt manuell beseitigt werden Pessimistische Mechanismen (lock-modify-unlock) o System verbietet gleichzeitiges Bearbeiten des Dokuments durch verschiedene Personen (Sperrprotokolle) Beide Mechanismen haben Vor- und Nachteile Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 8  Versionsverwaltung: Grundsätzliche Konzepte Pessimistischer Ansatz Ablauf zur Bearbeitung einer Datei file.txt checkout file.txt Zwischen checkout und commit kann kein anderer Nutzer commit file.txt die Datei verändern. Vorteil: o Keine Konflikte, da keine parallele Bearbeitung o Klare Verteilung der Verantwortung, mehr Sicherheit Nachteil: Genaue Syntax und Optionen o Verzögerung anderer Entwicklungen der Kommandos hängen vom Versionsverwaltungssystem ab. Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 9 Versionsverwaltung: Grundsätzliche Konzepte Optimistischer Ansatz checkout file.txt update - Nutzer aktualisiert seine lokale Kopie des Repositories commit file.txt - Nutzer übergibt seine lokale Kopie an das Repository (Versionsnummer wird inkrementiert) update und commit sind (nahezu) jederzeit erlaubt Vorteil: o Paralleles Arbeiten möglich Nachteil: o Evtl. entstehen Konflikte o Mergen der parallelen Versionen erforderlich  kann arbeitsintensiv sein  teilweise unterstützt durch Werkzeuge Genaue Syntax und Optionen der Kommandos hängen vom Versionsverwaltungssystem ab. Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 10 Versionsverwaltung: Grundsätzliche Konzepte Konflikte Konflikte werden in der Datei im Arbeitsverzeichnis markiert: > Änderung 1: Änderungen in Datei, in die gemergt werden soll, z.B. bei einem update die lokale Datei im privaten Arbeitsverzeichnis Änderung 2: Änderungen in Datei, von der gemergt werden soll, z.B. bei einem update die Datei im Repository Konflikte müssen vom Benutzer in seiner Arbeitskopie von Hand korrigiert werden. Hinweis: Konflikte entstehen nur im lokalen Arbeitsverzeichnis, niemals im zentralen Repository o commit einer Datei mit Konflikten wird verhindert! Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 11 Versionsverwaltung: Grundsätzliche Konzepte Mergen von Dateien Für Textdateien existieren gute Merge-Algorithmen o Java, Latex, … somit gut vergleichbar und mergebar Für binäre Dateien müssen separate Merge-Algorithmen verwendet werden Frage: Was passiert, wenn der Nutzer ein commit durchführt, und dabei Änderungen im Repository noch nicht in sein Arbeitsverzeichnis übernommen hat? Antwort: Wird durch Versions-Management-System verboten. Versions-Management-System fordert, dass erst update ausgeführt wird Commit erst danach möglich o Commit nur möglich, wenn lokales Arbeitsverzeichnis konfliktfrei ist Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 12  Versionsverwaltung: Grundsätzliche Konzepte Tagging Kennzeichnung bestimmter Versionen o Damit auf eine bestimmte Version des Systems leicht zugegriffen werden kann Ziel: selbst bestimmten Namen an eine Version vergeben, um diese Version leicht wiederzufinden o Sehr sinnvoll, falls eine Version einen bestimmten Meilenstein im Projekt darstellt. Beispiel: Tag „Release 3.4“ o Kennzeichnet alle Versionen, die zum Release 3.4 des Systems gehören o Zugriff auf genau diese Versionen durch den Tag möglich – die Versionsnummer muss nicht bekannt sein Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 13 Versionsverwaltung: Grundsätzliche Konzepte Branching Nicht alle System-Entwicklungen sollen im gleichen Entwicklungszweig stattfinden. Besser ist: Jedes Teilprojekt / Team besitzt einen eigenen, temporären Entwicklungszweig, damit sich die parallelen Entwicklungen nicht gegenseitig behindern. Der allgemeine, zentrale Entwicklungszweig heißt Master- oder Main- Branch Zusätzlich können weitere Branches / parallele Entwicklungszweige vom Main-Branch abgehen o Und später wieder mit diesem vereinigt werden. Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 14 Versionsverwaltung: Grundsätzliche Konzepte Main-Branch: Versionen des Develop: Branch zur Integration der Produktivsystems (verteilt an Kunden) Feature-Entwicklungen Bugfixing: Branch zur Korrektur wichtiger Feature „xyz“: Branch zur Fehler im Produktivsystem Implementierung des Features xyz Release: Branch zur Vorbereitung eines System-Releases Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 15 Versionsverwaltung: Grundsätzliche Konzepte Welche Dokumente und Dateien gehören ins Repository? Alle Dokumente und Dateien, die zur Software und ihrem Entwicklungsprozess gehören und nicht automatisch aus den anderen Dateien oder Dokumenten generiert werden können o z.B. Keine temporären Java-Dateien *.class Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 16 2.3 Zentrale und dezentrale Versionsverwaltung: Zentrale Versionsverwaltung Alle Dateien werden in einem zentralen Repository verwaltet. Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 17 Versionsverwaltung: Zentrale Versionsverwaltung Beispiel: Subversion (SVN) Open Source System zur Versionsverwaltung Offizielle Webseite: http://subversion.apache.org/ Online Buch: http://svnbook.red-bean.com/ SVN bietet selbst keine Unterstützung für Branches und Tags Lediglich das Konzept der Kopie Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 18 Versionsverwaltung: Zentrale Versionsverwaltung Zentrales Repository oft problematisch Single point of failure o Komplette Zerstörung bei Ausfall, Brand, etc. o Häufig langsam (z.B. bei weltweiten Teams) Kein Arbeiten ohne Netzverbindung o Historie nur auf Server verfügbar o Commits nur online auf Server möglich Keine (einfachen) Team- / Teilprojekt-Integrationen möglich Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 19 Versionsverwaltung: Dezentrale Versionsverwaltung Git http://git-scm.com/ aktueller Industrie-Standard kein zentrales Repository, sondern jeder Entwickler hat eigenes Repository und eigenen Arbeitsbereich o git init: legt leeres lokales Repository an o checkout und commit zur Interaktion mit eigenem, lokalem Repository Verteilte Repositories können lokale Änderungen an andere Repositories übertragen Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 20 2.4 Versionsverwaltung mit Git Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 21 Versionsverwaltung mit Git Interaktionen mit einem entfernten Repository git clone : ein existierendes entferntes Repository inkl. gesamter Projekthistorie für eigenen Gebrauch kopieren – ein Klon wird erzeugt. Quellrepository wird als origin-Remote vermerkt git push: Änderungen im lokalen Repository an ein entferntes Repository übertragen git pull: Änderungen aus einem entfernten Repository an eigenes Repository übertragen und integrieren Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 22  Versionsverwaltung mit Git Wie synchronisieren sich Entwickler, die gemeinsam an einem Projekt arbeiten? Lösung: Häufig existiert per Konvention ein „Master-Repository“ Versionsnummern in dezentraler Versionsverwaltung Kein zentrales Repository => kein zentrales Hochzählen der Versionsnummer möglich Lösung: Berechnung einer eindeutigen ID o Kennzeichnet eindeutig einen Commit o Auf Basis des Inhalts aller Dateien (SHA-1 Hashwert) o Bsp.: 9a034128a329f4fb7a53043dd1d1e8f74bfc91fc Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 23 Versionsverwaltung mit Git o git checkout : Wechsel zwischen Branches – Inhalt des Branches wird ins Arbeitsverzeichnis kopiert o git add : neue Datei, geänderte Datei aus Arbeitsverzeichnis in Staging Area einfügen  git add –A oder –all: alle neuen, geänderten und gelöschten Dateien werden zur Staging Area hinzugefügt (ohne die exakten Dateien anzugeben) o git rm : Datei aus Arbeitsverzeichnis und aus Index entfernen o git commit: Änderungen aus der Staging Area in das lokale Repository übertragen o git branch : Anlegen eines neuen Branches o git merge : Mischt den Branch in den aktuellen Branch, d.h. alle commits aus werden in dem aktuellen Branch übernommen o git tag : vergibt einen Namen für einen Commit = erzeugt Zeiger auf einen bestimmten Commit Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 24 Versionsverwaltung mit Git Wichtig: commit fügt nicht jede geänderte Datei automatisch in das lokale Repository ein! Geänderte (und neue) Dateien müssen zuerst in den Index (= Staging Area) hinzugefügt werden Commit behandelt nur Änderungen, die dort eingefügt wurden Warum 2-stufiges Konzept? Manchmal arbeitet man an mehreren Dingen zur gleichen Zeit o Bsp.: zwei Bugfixes o Logisch sollten dieses auch zwei Commits sein – bessere Nachvollziehbarkeit Durch Staging Area kann man explizit die Änderungen eines Commits auswählen Zu faul? o git commit –-all:  es werden automatisch alle veränderten und gelöschten Dateien zur Staging Area hinzugefügt und dann committed  Neu erzeugte Dateien werden hierbei allerdings nicht berücksichtigt und müssen manuell zur Staging Area hinzugefügt werden Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 25 Versionsverwaltung mit Git Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 26 Versionsverwaltung mit Git Commit Abbildung des ganzen Projekts zu einem Zeitpunkt Ein Commit speichert o Alle Dateien (als Delta vom Vorgänger) o Seinen Vorgänger o Commit-Nachricht, Autor, Zeit, … Identifiziert durch Hashwert C1 C2 C3 Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 27 Versionsverwaltung mit Git Git Repository: Menge aller Commits o Jeweils mit Verweis auf Vorgänger o Gespeichert im Verzeichnis.git (wird bei Aufruf git init angelegt) Menge von Zeigern auf bestimmte Commits o master = Zeiger auf Kopf des initialen Branch. Dieser Branch wird automatisch erzeugt o Für jeden erzeugten Branch einen Zeiger mit dem Branchnamen, der dann auf den Kopf dieses Branches zeigt o HEAD zeigt auf den aktuell bearbeiteten Commit (also derjenige, der mit checkout ausgewählt wurde und im Arbeitsverzeichnis vorliegt) o Für jeden erzeugten Tag einen Zeiger auf den entsprechenden Commit Schöne Animation zum Ausprobieren: http://learngitbranching.js.org Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 28 Versionsverwaltung mit Git Befehle zur Analyse des lokalen Repositories: git status Liefert den Status des lokalen Repositories (im Verhältnis zum entfernten Repository) Mögliche Antworten des Befehls: o „Your branch is up to date with ´origin/master´“  Das lokale Repository besitzt keine neueren commits als das entfernte Repository  Hinweis: Es könnten jedoch im entfernten Repository neuere Commits (von anderen Entwicklern) vorliegen. Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 29 Versionsverwaltung mit Git o „Changes not staged for commit“  Änderungen wurden im Arbeitsbereich vorgenommen, wurden aber noch nicht in den Staging-Bereich übertragen.  Aktion: git add für diese Änderungen ausführen o „Untracked files“  Es existieren neue Dateien im Arbeitsbereich, die noch nicht im lokalen Repository enthalten sind.  Aktion: git add für diese neuen Dateien ausführen Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 30 Versionsverwaltung mit Git o „Changes to be committed:“  Änderungen befinden sich in der Staging-Area, wurden aber noch nicht in das lokale Repository committed  Aktion: git commit durchführen Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 31 Versionsverwaltung mit Git o „Your branch is ahead of 'origin/master' by 1 commit.”  Das lokale Repository ist gegenüber dem entfernten Repository einen commit voraus.  Es wurden also Änderungen aus dem Arbeitsbereich in das lokale Repository committed, aber noch nicht an das entfernte Repository gepusht.  Die beiden Repositories sind nicht synchron.  Zum Übertragen der commits an das entfernte Repository: git push ausführen Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 32  Versionsverwaltung mit Git Befehle zur Analyse des lokalen Repositories: git log o Zeigt alle commits des lokalen Repositories an o Beispiel mit 3 commits: Nummer (= Hashwert) des commits Commit- Nachricht Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 33 Versionsverwaltung mit Git git log --graph o Zeigt alle commits des lokalen Repositories mit ihren Abhängigkeiten als Graph an Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 34 Versionsverwaltung mit Git git log --oneline o Zeigt alle commits des lokalen Repositories als Einzeiler, d.h. sehr kompakt, an Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 35 Hilfreiche Referenzen zu Git Git: https://git-scm.com/ Freies Ebook „Pro Git“ von Scott Chacon und Ben Straub: https://git-scm.com/book/en/v2 A Visual Git Reference http://marklodato.github.io/visual-git-guide/index-en.html TortoiseGit: Windows Shell Interface to Git – als Kontextmenü im Windows Explorer https://tortoisegit.org/ Gitlab des Informatik-Labors: https://gitlab.nt.fh-koeln.de/ In diesem Git werden wir für Sie einen Account anlegen. o Sie erhalten hierzu eine Email, nachdem der Account angelegt wurde. In diesem Git erfolgt die Abgabe der Praktikums-Lösungen! In diesem Git stelle ich Code für die Übungen und die Praktika zur Verfügung! Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 36 Versionsverwaltung: Zusammenfassung Entwicklung im Team erfordert eine Versionsverwaltung Konzepte o Repository + lokale Arbeitskopien + spezielle Zugriffsoperationen o Konsistenzmechanismen: pessimistisch vs. Optimistisch o Branching Zentrale Versionsverwaltung o Subversion Dezentrale Versionsverwaltung: o Jeder hat eigenes Repository o Austausch der Änderungen zwischen Repositories möglich o Werkzeug: Git Aufbau eines Git-Repositories (Commits, Zeiger, Branches, Staging Area etc.) Wichtige Befehle in Git und ihre Wirkung: o push / pull o add / commit / checkout o branch / tag Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 37 Lernziele Sie kennen die wesentlichen Konzepte der Versionsverwaltung. Sie können die beiden Konsistenzmechanismen erklären. Sie kennen verschiedene „Typen“ von Branches und deren Bedeutung Sie kennen die Unterschiede zwischen einer zentralen und einer dezentralen Versionsverwaltung Sie können die Konzepte und Eigenschaften von Git erläutern Aufbau eines Git-Repositories Wichtige Befehle und ihre Wirkung: Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 38 Vorführung Git Siehe separates Video Prof. Dr. Hans W. Nissen Software Engineering, Kapitel “Versionsverwaltung” Folie: 39