@ -82,3 +82,46 @@ Durch automatisierte Refactorings ist es möglich Variablen-Namen noch im Nachhi
### Wiederholung
### Wiederholung
Bei einfachen Refactorings beschränkt sich die Änderung der Variablen-Namen auf die aktuelle Datei. Bei komplexen Refactorings werden die Änderungen der Signatur in einer Methode über mehrere Dateien automatisch übernommen und geändert. Dabei wird die Signatur so geändert, dass der Code weiter Compilierbar bleibt und das Verhalten nicht geändert wird.
Bei einfachen Refactorings beschränkt sich die Änderung der Variablen-Namen auf die aktuelle Datei. Bei komplexen Refactorings werden die Änderungen der Signatur in einer Methode über mehrere Dateien automatisch übernommen und geändert. Dabei wird die Signatur so geändert, dass der Code weiter Compilierbar bleibt und das Verhalten nicht geändert wird.
## SU 04 (16.11.2022)
### Lernziele
- Verschiedene Speichermoeglichkeiten unterschiedlcher Versionsstaende
- Source Code Management
- Vorteile Source Code Management
- Unterschied lokaler und distibutiver Versionsverwaltung
- Konzept von git
- Umgang mit git
- Commit-Grundsaetze (Moeglichst kleine Commits, Commits sauber halten (Versionen wurden umfangreich getestet und funktionieren))
- Uebersicht der verschiedenen Branches
- Master-branche (Existiert ueber ganze Laufzeit des Projekts, Auslieferung an Kunden)
- Develop-branche (Existiert ueber ganze Laufzeit des Projekts, fuer Features, jeder Commit sollte clean sein)
- Release-branche (Abzweig des Develop-branche fuer Tests und Bugfixes, keine neuen Features)
- Hotfix-branche (Kurze Laufzeit, spornt direkt von Master-branche, keine neuen features, nur hotfix)
- Feature-branche (Kurze Laufzeit, spornt von Develop-branche, ausfuehrliche Tests vor rebase in den Developbranche)
- Unterschiede merge und rebase
- Praktische Umsetzung in Git
- Neues git-Repository erstellen
- Neue Textdatei anlegen
- Repository-Status anzeigen lassen
- Textdatei zur Stage hinzufügen
- Aenderungen Commiten
- Historie Anzeigen lassen (mit und ohne Graph)
- Aenderungen im Respoitory anzeigen lassen
- kontrollierte und interaktive Uebernahme von Aenderungen einer Datei in die Stage
- Aenderungen an Dateien zuruecksetzen (nur in Stage sowie auch in Datei)
- neue Branches anlegen und zwischen den Branches wechseln
- Alle commits von allen Branches anzeigen lassen
- Mergen von Branches
- Merge rueckgaengig machen
- Merge abbrechen
- Markierungen anlegen
- Rebase von Branches
- Konflikte aufloesen, die beim merge oder rebase entstehen koennen
### Erkenntnis
Es gibt verschiedene Wege, Branches zusammenzufuehren. Beim merging kann man gut das parallele arbeiten sehen, die Historie stellt weiterhin eine Zeitlinie dar. Allerdings wird jedes Mal ein Merge-Commit erstellt, weswegen die Historie schnell unuebersichtlich werden kann. Beim rebasing bleibt die Historie sauber. Die Historie stellt jedoch keine Zeitlinie mehr dar. Das Neu-Scheiben der Projekthistorie kann zu Schwierigkeiten der Rueckverfolgbarkeit führen.
### Wiederholung
Aus dem Master-branche, welcher die Auslieferungsversion an den Kunden darstellt, spornt nur der Develop-branche und der Hotfix-branche. Der Hotfix-branche existiert nur kurze Zeit und dient dazu Bugs zu fixen, die dringend behoben werden muessen, wohingegen der Develop-branche ueber die gesamte Laufzeit des Projekts besteht und die Commits immer clean gehalten werden sollen. Um dies sicherstellen zu koennen und trotzdem das Projekt weiterentwickeln zu koennen spornen aus dem Develop-branche noch der Release-branche (zum Testen und fuer Bugfixes) sowie der Feature-branche (zur Weiterentwicklung).