Delete Lerntagebuch4.md

Lerntagebuch4.md

@@ -1,115 +0,0 @@
-##SU 04  Lerntagebuch   (15.11.2022)
-##Daria Popa        fdai7460        Matrikelnummer:1436682
-
-### Lernziel => Was waren die wesentlichen Inhalte der letzten Vorlesung/Übung?
--Git und seine Vorteile:
-    • Der Zugriff auf letzte gespeicherte Arbeit ist immer möglich
-    • Zugriff auf Produktion, Entwicklung
-    • Vergleich zwischen vorherigen Versionen möglich
-    • Einfach Lokal zu speichern/ kopieren
-    • Einfach zu verstehen und einfache Methoden
-    
--Git ist zentralisiert, also die Geschichte bzw. Verlauf existiert auf einer zentralen Netzwerkressource. Die Entwickler haben nur eine funktionale Kopie von der Datei.
-    Pro:
-    • Jeder Commit ist für jedes Gruppenmitglied verfügbar
-    • Man kann immer auf die aktuelle Datei zugreifen und die umändern, was für jeder sichtbar ist
-    • Eine zusätzlich Kopie
-    • unbegrenzte Ressourcen für das Repository
-
-    Contra:
-    • Das parallele Arbeiten verursacht mehrere verschiedene Dateien aus einer Datei.
-    • Nach dem Puschen verschiedenen Dateien von verschiedenen Glieder, kommt zum Merg, also alle Dateien werden zusammen gefasst
-    • Online Arbeiten nicht möglich
-    
--Git ist verteilt, das heißt, dass jeder Entwickler seine eigene Version der Geschichte hat.
-    Pro:
-    • Es erfordert keinen zentralen Server
-    • Jeder kann es auf seinem eigenem Computer, Lokal es bearbeiten 
-    • Keine direkte Kopie
-    • Lokale Experimente bleiben privat
-    • Funktioniert auch ohne ständigen Internetzugang
-
-    Contra:
-    • Die Lokale Geschichten sind nicht mit einander synchronisiert
-    • Die Datei wird nicht mehr geschützt, wenn gleichzeitig Veränderungen vorgenommen werden
-    
--In dem Konzept von Git, hauptsächlich geht es darum, zu zeigen, wie viel Mal eine Datei verändert worden ist. Jedoch, es basiert nicht auf Dateien. Hier gibt es Branches, die etwas Vergleichbares wie eine Etikette bzw. Beschriftung für den Commit ist. Sowie eine Staging area, die eine Datei ist, die das Teil den nächsten Commit wird, was in Grunde die Datei verändern wird.
-
--Kurze Commits verwenden, diese ermöglichen automatische (oder manuelle) Lösung der Konflikte. Dadurch ist auch der Verlauf mehr detailliert und übersichtlicher aufgebaut, sodass die Veränderungen einfach zu finden sind.
-
--Saubere Commits also erst committen, wenn das ganze Projekt alle Tests bestanden hat und alle wesentliche Informationen enthalten sind.
-    • Committen, wenn:
-        ○ ingle New Behavior abgeschlossen worden ist
-        ○  Single Refactoring-Schritt abgeschlossen worden ist
-        ○ Merge/Rebase-Konflikte behoben worden sind
-    
--Branches unterteilt sich in:
-    • Master => eine Standardbezeichnung
-        ○ Wird vom ursprünglichen Commit erzeugt
-        ○ Unendliche Lebensdauer
-        ○ Alle Commits haben eine Versionsnummer
-        ○ Es sind keine direkten Commits, sondern Merge
-        
-    • Hotfix => Schnelle Reparatur zu dem Code
-        ○ Haben kurze Lebensdauer
-        ○ Kommen direkt von Master 
-        ○ Jeder Entwickler kann es committen
-        ○ Merge zurück zu Develop und Release
-    • Release => entstehen aus Develop, wird veröffentlicht 
-        ○ Kurze Lebensdauer, nur währen Feature frezze
-        ○ Es ist keine neue Feature, wenn dann nur kleine Reparaturen
-        ○ Jeder Entwickler kann es committen
-        ○ Merge zurück zum Develop
-    • Develop => Hier wird Code entwickelt
-        ○ Unendliche Lebensdauer
-        ○ Erster Commit startet das Programm
-        ○ Ist immer Versandbereit, alle autDmatische Test sind bestanden
-        ○ Jeder Entwickler kann einen versandfertigen feature commiten
-    • Feature =>
-        ○ Begrenztes Lebensdauer
-        ○ Kommen von develop und kehren dahin zurück
-        ○ Nur zugewiesene Entwickler sollen committen
-   
--Merge
-    Nutzen:
-    • Ein sichtbarer Verlauf der Parallelarbeit
-    • Die Lösung des Konflikts nur ein mal möglich
-    • konfigurierbare automatische Konfliktlösung
-
-    Nachteile:
-    • Komplexer Arbeitsverlauf
-    • Konfliktlösung zwischen Zuständen
-    
-    Wähle Merge wenn:
-    • Aktueller Branch ist ein Developer oder Master
-    • Der Verlauf soll synchronisch zu der Zeit und Ort sein
-    •Dein aktueller Branch war schon mindestens einmal ,,gemerge' (merged).
-    
--Rebase 
-    Nutzen:
-    • Sauberer Verlauf = Alle Feature werden nacheinander übertragen
-    •  Lösung des Konflikts mit dem Commit (weniger Änderungen auf einmal)
-        ○ Bevorzugt eine automatische Lösung
-        ○ Einfacher eine manuelle Lösung
-    Nachteil:
-    • Verlauf zeigt nicht wie die genaue Zuordnung war
-    • Solche Commits können widersprüchlich sein
-    • Die Commits haben dann keinen Verlauf, wovon sie entstanden sind
-    
-    Wähle Rebase wenn:
-    • man an einem Feature immer noch arbeitet, er unvollendet ist und noch nicht mit den anderen Branchen verbunden werden soll
-    • Für sauberes Verlauf
-    • Um ”squash-commit” zu vorbereiten
-    • Eigener Branch viele Commits hat
-    
-    
-### Erkenntnis => Was kann ich für das Gruppenprojekt anwenden?
-Git zu verstehen ist sehr wesentlich, denn so kann die Gruppe genau und transparent arbeiten. Je mehr Entwickler (bzw. Mitglieder einer Gruppe), desto mehr Commits, die miteinander verknupft werden müssen. Deswegen kurze und saubere Committs vereinfachen der Gruppe die Veränderungen nachzuvollziehen und zusätzliche Fehler möglich schnell bekämpfen zu können.
-
-
-### Wiederholung => Einen Begriff/Ein Thema in eigenen Worten erklären.
-Git besteht aus unterschiedlichen Committen, die sich wiederum aus verschieden Branches zusammensetzten. Diese haben seine Funktionen und dadurch vereinfachen sie das Arbeiten im Git, als auch machen den Verlauf übersichtlicher. Wenn zwei Commiten gleichzeitig entstehen, die sich auf die gleiche Programmierzeile beziehen, kann man den Commit mit Merge und Rebase umändern.
-
-
-###Kritik => Was möchte ich dem Dozenten mitteilen?
-