@ -69,5 +69,71 @@ Separations of Concern ist ein Prinzip von SOLID. Diese besagt, dass man ein Pro
ein Problem behandeln. Um eine gute Übersicht über das Programm zu erhalten.
ein Problem behandeln. Um eine gute Übersicht über das Programm zu erhalten.
# Woche 4 - git - efecitve
## Lernziele
# Woche 4 SCM
## Lernziele/Takeaway
In der dieser Vorlesung haben wir über die Sicherheit und Vertrauen gesprochen. Den Vergleich zwischen zentralisierter und verteilte SCM gesprochen. Ebenfalls wurde über die Konzepte von git gesprochen.
### Sicherheit schafft Vertrauen:
Die Vorteile sind das permanente zugreifen auf letzte bzw. verschieden Arbeitsstände.
Das Zugreifen ermöglicht auch das bearbeiten, produzieren während einer Bearbeitung.
Vergleichen von Daten sind ebenfalls möglich.
Man kann lokale Kopien erstellen und archivieren z.B. zip. Es werden hierbei keine speziellen Tools benötigt. Es ist einfach zu unterscheiden, jedoch wird sehr viel Speicher benötigt. Daher ist eine externe Festplatte empfehlenswert. Es wird kein Commit erstellt. Das navigieren und suchen nach Daten ist sehr umfangreich, da sehr viele Kopien erstellt werden. Diese Kopien haben auch keine Verbindung zueinander. Einfach gesagt es wird für jedes Speichern eine Datei erstellt. Daher ist das suchen durch ein Tool nicht möglich, da verschieden Dateien angelegt werden.
### SCM (Source Code Management
Beim SCM wird viel Speicher eingespart, indem keine Kopien erstellt werden, sondern Kopien werden aktualisiert. Die Daten können in sehr feinen abständen gesichert werden. Die Änderungen werden Kommentiert, was die suche von bestimmten Ständen erleichtert. Diese kann man sich wie ein Baum vorstellen. Es werden zweige erstellt. Man kann somit die Verbindung der Daten miteinander nachvollziehen. Die Zusammenführung der Daten ist automatisiert.
Man Unterscheidet zwischen Zentralem und distributiv Netzwerke, die jeweils Vorteil sowie Nachteile mit sich bringen.
Zentral:
Beim zentralen Netzwerk wird auf einem Netzwerk gearbeitet.
Die Entwickler haben nur Kopien.
Alle Entwickler sind im aktuellen Stand. Änderungen sind reserviert und können lediglich nur von einem Bearbeitet werden. Einfacher Backup und Wiederherstellung und man hat kein Limit bei Ressourcen und Repository.
Die Nachteile sind darin, dass eine zentrale Instanz ist erforderlich. Parallele Arbeit auf Daten sind nicht möglich. Die Verzweigungen und sind für alle sichtbar und eine offline Arbeit ist ebenfalls nicht möglich.
Distribut:
Alle Entwickler haben eine eigene Historie.
Es wird kein Netzwerkzugang benötigt und mehrere Bedienungen sind möglich. Man kann implizite Backups erstellen und man arbeitet Lokal – und ist privat.
Die Lokalen Daten werden nicht synchronisiert und einen Schutz für die gleichzeitige Änderungen sind nicht vorhanden.
### Git
Beim Konzept von git sind Verschiebungen identifizierbar. Git basiert nicht auf Dateien, sondern lediglich an Änderungen der Dateien. Nach jeder Änderung sind deshalb auch die Vorgänger erkennbar. Die Branches sind Labels auf Commits z.B. diese Branche gehört ab jetzt einem anderen Commit.
## Commits
Die Commits sollten klein und sauber gehalten werden. (Kurz und verständlich).
Kurze bzw. Kleine Commits ermöglichen Konflikte automatisch zu lösen. Auch das manuelle lösen von Problemen ist einfacher. Änderungen sind einfacher, weil die suche der Historie einfacher ist.
Commit ist, wenn ein Projekt komplett abgeschlossen und bestanden ist.
Man kann sich ein Kreis vorstellen. Test -> Code -> Refactor.
- Einzig neue Verhalten ist abgeschlossen
- Einzig neue Refacoring abgeschlossen.
- Merge/Rebase Konflikte sind behoben.
## Branching
# Master
Haben eine unendliche Lebensdauer und einen Verantwortlichen „Committer“. Jeder Commit verweist auf einen Versand. Commits sind mit Versionsnummern gekennzeichnet. Es sind keine direkten Commits, nur Merges aus dem Realese- oder Fix-zweig erlaubt.
#Develop
Erstes Commit ist das Projektstart. Ist immer im versandbereiten Zustand und Testdurchläufe sind automatisiert. Jeder Entwickler kann Feature festschreiben (Bis Build-Server).
# Release
Hat eine begrenze Lebensdauer während des Einfrierens einer Funktion. Keine neuen Funktionen werden angelegt, sondern Fehler werden behoben. Jeder Entwickler kann sich verpflichten. Release sind auch Kandidaten von Tags. Der Build-Server sollte den Zweig wieder mit dem Develop-Branch zusammenführen.
# Hotfix
Hat eine Kurze Lebensdauer. Erscheint aus dem Master (Letze Commit). Ist keine neue Funktion, sondern nur zum schnellen beheben von Fehlern.
# Feature.
Hat eine begrenzte Lebensdauer und stammt aus Develop. Sollte ein neues Commit in dem Entwickler basieren und zusammenführen.
## Merge
Die Vorteile liegen darin, dass eine Parallelarbeit visualisiert wird. Die Lösung bei einem Merge wird pro Zusammenführen nur einmal gemacht. Automatische Konfliktlösung kann mit (-s recursive -X ours|theirs) realisiert werden.
Komplexe Vergangenheit Grafik und Konfliktlösung zwischen den Finalzuständen sind jedoch ein Nachteil.
## rebase
Hat eine Saubere Vergangenheitsgraph (man sieht alles: Funktionen, Commits und wies es aufeinander folgt). Ein automatischer Konfliktlösung ist wahrscheinlicher und auch das manuelle Lösung ist einfacher
Die Nachteile sind das wir keine Zeitachse über den verlauf haben. Commits können zu Problemen führen.
Eein Rebase wird erst bevorzugt, wenn das arbeiten an einem unvollendeten Feature, noch keine Zweige intergriert wurden. Eine Saubere Historie wird erwünscht und beinhaltet viele Commits.
Merge wird verwendet, wenn der aktuelle Zweig ein Develop oder ein Master ist. Die Historie sollte mit der Zeitachse synchron bleiben und wenn der aktuelle Zweig zusammengeführt is.t
fdai4796
2 years ago