Update Lerntagebuch.md

Lerntagebuch.md

@@ -219,3 +219,173 @@ Das Entwurfsmuster "Nachrüstungsschnittstelle" kann man im Prinzip als eine
 Entwurfsmuster sind schwer vorstellbar, da keine konkreten Beispiele gegeben waren. Man kann sich zwar vorstellen was beispielsweise eine abstrakte Fabrik macht, hat aber keine Ahnung wie man das konkret anwenden soll. Ich denke, Codebeispiele würden hier vielleicht eher helfen als verwirren.
 
 ---
+
+
+## SU 04 (14.11.2023) - Source Code Management
+
+### Lernziel
+
+**Seminarischer Unterricht:**
+ 
+SCM:
+- "Source Code Management"
+- Ermöglicht Zugriff auf verschiedene Stände der Entwicklung
+- Ermöglicht es, auf funktionierenden Stand zurückzukehren
+- Ermöglicht Vergleich der Entwicklung
+- Ermöglicht das Entwickeln von neuen Features, die nicht sofort in den Stable Build kommen sollen
+- Erleichtert Zusammenarbeit mit anderen Entwicklern
+
+Einfache Möglichkeiten:
+- Lokale Kopien
+- Kopien in Zip-Ordnern → Spart Platz
+- Kopien auf Netzlaufwerken oder in der Cloud
+- Pro:
+    - Es werden keine Extra-Tools oder Hardware benötigt
+    - Diff-Tool kann benutzt werden, um Änderungen zwischen Backups zu erkennen
+- Con:
+    - Hoher Festplattenspeicherverbrauch
+    - Keine "Commit-Message" die Grund für Änderung anzeigt
+    - öftere Backups brauchen mehr Speicherplatz → Man neigt dazu, seltener Backups zu machen
+    - Schwer nach spezifischen Änderungen zu suchen
+    - Zusammenführen von verschiedenen Ständen schwierig
+    - System für Backup-Namen wird oft nicht eingehalten
+
+Bessere Möglichkeit: SCM
+- Speichert nur die Änderungen an Dateien → optimiert für möglichst geringen Speicherverbrauch
+- Speicherverbrauch steigt mit Menge der Änderungen → Kleinere Backups sind nicht mehr ineffizient
+- Beschreibung des Grunds der Änderung
+- Einfache Navigation in Änderungen
+- Änderungen an der gleichen Datei von verschiedenen Usern können einfach zusammengefasst werden
+- Baumstruktur der Änderungen → nachvollziehbar
+
+Zentralisiert:
+- Dateien liegen auf Server, User lädt sich die Dateien zum Bearbeiten herunter
+- Dateien die gerade bearbeitet werden sind für andere User gesperrt
+- Pro:
+    - Jeder Commit für jeden sichtbar
+    - Das Sperren von Dateien bei aktueller Bearbeitung verhindert, dass zwei User die gleiche Zeile bearbeiten
+    - Leichte Backups durch Server-Admin
+    - Speicherplatz in Server relativ einfach erweiterbar
+- Con:
+    - Der Server wird benötigt → Extra-Gerät was immer laufen muss
+    - Wenn ein User vergisst seine Datei wieder freizugeben ist die Datei gesperrt → Problem bei Urlaub, Unfall etc. 
+    - Branches und Merges direkt für alle verfügbar → Auch halbfertiger Code, wird zum Problem wenn andere User darauf aufbauen
+    - Offline arbeiten nicht möglich
+
+Dezentralisiert (Verteilte Systeme):
+- Jeder Entwickler hat eigene History an Änderungen
+- Pro:
+    - Keine zentrale Instanz benötigt, aber möglich → auch mehrere
+    - Die meiste Zeit kann man offline arbeiten → Online-Zugang nur zum Hochladen wenn man fertig ist
+    - Jeder Entwickler bildet eine Art Backup
+    - Lokale Experimente bleiben privat
+- Con:
+    - Lokale änderung ist nicht synchron mit Server → Erst "push" veröffentlicht Änderungen
+    - Kein Schutz gegen gleichzeitiges Ändern einer Datei von zwei Usern
+
+Git:
+- Generelles:
+    - Entwickelt von Linus Torwalds
+    - Commits sind änderungsbasiert
+    - Man kann nur ganze Commits auschecken → Verhindert es, dass zum Beispiel Methoden nur in einer Datei geändert werden
+    - SHA-Checksum zur Sicherung und Nachverfolgung von Änderungen
+    - Zweige → Mit Commit gekennzeichnet, mit neuem Commit aktualisiert
+    - Staging → Eine Art Safe Space, auch wenn man den Zweig wechselt
+- Commits:
+    - Möglichst kleine Commmits reduzieren Potenzial für Konflikte
+    - Kleine Commits erleichtern Git das Zusammenführen von verschiedenen Änderungen
+    - Cherry Pick → Ermöglicht es, die Commits von anderen Developern zu übernehmen
+    - Je kleiner der Commit desto besser nachvollziehbar
+    - Commits sollten keinen fehlerhaften Code enthalten
+    - Committen nach Programmieren einer Funktion oder nach einem Refactoring-Schritt oder wenn merge/base-Konflikte gelöst wurden
+- Branches
+    - Master-Branch
+        - Der Branch den man normalerweise geclont bekommt
+        - Jeder Commit eine fertige Version
+        - Wird nie enden
+        - Nicht jeder soll darin committen dürfen
+        - Nicht manuell mergen → CIS
+    - Development-Branch
+        - Stand im Dev-Branch sollte immer im "shippable"-Stadium sein
+        - Sammelt Features
+        - Lebt unendlich
+        - Erster Commit erzeugt den Branch
+        - Jeder Developer kann ein Feature hinzufügen, CIS wäre aber besser
+    - Release-Branch
+        - Vorbereitung einer Software-Version
+        - Von Development abgezweigt
+        - Nur noch Fixes
+        - Jeder Entwickler kann Fixes einbringen
+        - Release-Candidate in Tag
+        - Build-Server muss fertigen Branch wieder in Development mergen, da Fixes auch dort vorhanden sein sollen
+    - Hotfix-Branch:
+        - Keine neuen Features, nur Hotfixes
+        - Zweigt von letztem Master-Commit ab
+        - Kurzlebig
+        - Jeder kann ändern
+        - Build-Server mergt hotfixes zu Dev und Release
+    - Feature-Branch:
+        - Existiert nur während Arbeit am Feature
+        - Spawnt von Develop
+        - Rebase/Merge Änderungen vom Dev-Branch
+        - Jeder kann committen, üblicherweise arbeiten aber nur die Entwickler des Features daran
+        - Sub-Feature-Branches
+- Merge:
+    - Zwei Zweige mit gleichen Vorfahren werden zusammengeführt
+    - Neuer Commit mit zusammengeführten Änderungen
+    - Kann automatisch von Git erzeugt werden, eventuelle Konflikte müssen manuell gelöst werden
+    - Pro:
+        - Gleichzeitige parallele Arbeit sichtbar
+        - Flags zur Behebung von Konflikten → "ours"/"theirs"
+    - Con:
+        - Komplexe Darstellung, wird mit mehr Entwicklern schlimmer
+        - Konflikte müssen auf den finalen Ständen gelöst werden → Viel auf einmal
+    - Wann mergen:
+        - Wenn man im Dev-Branch oder Master-Branch ist
+        - Wenn zeitliche Reihenfolge wichtig ist → Blockchains
+        - Wenn der aktuelle Stand schon gemergt wurde
+- Rebase:
+    - Commits der unterschiedlichen Branches werden Schritt für Schritt angewendet
+    - Pro:
+        - Git kann Änderungen leichter zusammenführen, da weniger auf einmal
+        - Auch manuelles Zusammenführen leichter
+        - Unit-Tests ermöglichen die Fehlersuche während einzelnen Schritten
+        - Darstellung als gerade Linie → Saubere Darstellung
+    - Con:
+        - History zeigt nicht mehr die zeitliche Entwicklung
+        - Jeder Commit kann einen Konflikt verursachen
+        - "Orphan" Commits, deren Änderungen schon übernommen wurden → Garbage Collector
+    - Wann Rebasen:
+        - Wenn man an einem Feature arbeitet was noch nicht in anderen Branches existiert
+        - Wenn man eine einfache History haben möchte
+        - Wenn man viele einzelne Commits mit Unit-Tests hat
+
+**Praxisübung:**
+Nützliche Git-Befehle:
+- status → Zeigt aktuellen Status des Repositorys an
+- add → Teilt Git den aktuellen Stand einer Datei mit → Staging-Area
+- commit → -m für Message, optionale Angabe einer Datei für direkten Commit
+- branch → Legt neuen Branch an
+- restore → Wendet den Stand aus Git auf die Datei an
+- switch → Wechselt Branch
+- log → Darstellung des Repositorys, Flags: "oneline" "graph" "all"
+- checkout
+- reset → Resettet Branch auf vorherigen Stand → "hard" verändert auch Datei
+- merge → Flags: "-s recursive -X ours/theirs"
+
+
+### Erkenntnis
+
+Aus dem Seminarischen Unterricht und der Übung kann ich für das Gruppenprojekt das neue Wissen über die Funktionsweise und die Bedienung von Git mitnehmen.
+
+
+### Wiederholung
+
+Der Release-Branch in Git dient der Vorbereitung einer Software-Version. Er zweigt von einem Commit im Develop-Branch ab. Im Release-Branch werden nur noch Bugs entfernt und gefixt. Die fertige Version landet dann sowohl im Master-Branch als auch im Develop-Branch, damit die Fixes auch da vorhanden sind.
+
+
+### Kritik
+
+Keine
+
+---