Philipp Hartmann
2 years ago
1 changed files with 94 additions and 1 deletions
@ -1 +1,94 @@ |
|||
Lerntagebuch |
|||
Lerntagebuch für Programmiermethoden und -werkzeuge von Philipp Hartmann |
|||
|
|||
# SU4 16.11.2022 |
|||
|
|||
## Lernzeiele (Was waren die wesentlichen Inhaltlichen Punkte der letzten Vorlesung - Stichpunktartig) |
|||
- Sourcecodemanagement |
|||
-- Einfache Navigation |
|||
-- Permanter Zugang zum letzten Arbeitszustand |
|||
-- Zugang zu verschiedenen Zuständen des Codes |
|||
-- Speichert nur die Änderung |
|||
|
|||
- Möglichkeiten zur Sicherung des Sourcecodes |
|||
-- zip archiv |
|||
-- Internetkopien |
|||
-- lokale Kopien |
|||
|
|||
- Zentralisierte SCM |
|||
-- Vorteile: |
|||
- jeder Commit ist für alle Verfügbar |
|||
- jeder weiß wer am Projekt gearbeitet hat |
|||
- einfaches backup und Wiederherstellung |
|||
- unendliche Ressourcen für das Repository |
|||
-- Nachteile: |
|||
- zentrale Instanz ist notwendig |
|||
- "locking" verhindert paralleles Arbeiten |
|||
- "branching" und "merging" ist direkt für alle sichtbar |
|||
- kein Offline arbeit möglich |
|||
|
|||
- Verteiltes SCM |
|||
-- Vorteile: |
|||
- kein zentraler Server nötig |
|||
- mehrere remotes möglich |
|||
- funktioniert ohne permanente Netzwerkverbindung |
|||
- implizierte Backups |
|||
- offline Arbeit /lokale "Experimente" bleiben Privat |
|||
|
|||
--Nachteile |
|||
- lokaler Verlauf ist nicht synchron |
|||
- kein Schutz gegen gleichzeitige Änderungen |
|||
|
|||
- Git Konzept |
|||
- basiert auf Veränerungen nicht auf Dateien |
|||
- commits/eingaben sind durch SHA geschützt |
|||
- branches sind labels mit commits |
|||
- staging area (Änderungen werden angesammelt bis sich ein commit lohnt |
|||
|
|||
- Commits |
|||
- clean commits |
|||
- sollten klein sein um Konflikte leichter zu lösen |
|||
- "cherry peak" Veränderungen sind leicht zu finden |
|||
|
|||
- Branches (master) |
|||
- unendliche Laufzeit |
|||
- bestimmt einen verantwortlichen Committer |
|||
- kommen vom initial commit |
|||
- alle commits im master branch müssen clean sein, denn dieser geht an die Kunden |
|||
|
|||
- merge |
|||
-- Vorteile: |
|||
- verlauf visualisiert parallele Arbeit |
|||
- konfliktlösung nur einmal pro merge |
|||
- konfigurierbare automatische Konflikt lösung |
|||
|
|||
--Nachteile: |
|||
- komplexer Verlauf |
|||
- konfliktlösung zwischen den finalen Zuständen |
|||
|
|||
- rebase |
|||
-- Vorteile: |
|||
- "clean" Verlaufsgraph (Alle Merkmale aufeinanderfolgenden commits) |
|||
- konfliktlösung pro Commit weniger Änderungen auf einmal |
|||
|
|||
-- Nachteile: |
|||
- verlauf zeigt keine timeline an was wann gemacht worden ist |
|||
- jeder commit kann Konflikte mit sich bringen |
|||
|
|||
|
|||
|
|||
|
|||
## Erkenntnis (Was kann ich für das Gruppenprojekt anwenden -2-3 Sätze) |
|||
Ich kenne jetzt das Konzept von Git und weiß wie ich es im Gruppenprojekt verwenden kann. |
|||
Außerdem weiß ich jetzt wie ein clean commit aussieht und weiß welche branches es gibt um mein Gruppenprojekt sauber und übersichtlicher zu halten. |
|||
|
|||
|
|||
|
|||
## Wiederholung (Einen Begriff/Ein Thema erklären - 2-3 Sätze) |
|||
Begriff erklären: merge |
|||
- Man vergleicht mehrerer Änderungen, welche an verschiedenen Versionen derselben Datei getätigt worden sind |
|||
- Ein Besipiel sind das Zusammenführen von Textdateien oder Verzeichnisstrukturen |
|||
|
|||
|
|||
|
|||
##Kritik (Kritik oder Lob für den Dozenten - Optional 2-3 Sätze |
|||
Nichts |
Write
Preview
Loading…
Cancel
Save
Reference in new issue