Browse Source

Update Lerntagebuch

remotes/origin/HEAD fetched-on-2023-11-27
fdai7968 1 year ago
parent
commit
ab9aab61c0
  1. 34
      Lerntagebuch.md

34
Lerntagebuch.md

@ -55,3 +55,37 @@ Die Anwendung von Entwurfsmustern in einem Gruppenprojekt bietet eine strukturie
### Wiederholung ### Wiederholung
Integrated Development Environments (IDEs) wie Eclipse oder Visual Studio Code bieten Entwicklern automatisierte Tools wie Code-Insights, Refactorings und Debugging-Werkzeuge. Diese Funktionen erhöhen die Produktivität im Team, da sie schnelleres Schreiben, Anpassen und Debuggen von Code ermöglichen. Die Auswahl einer geeigneten IDE basiert auf der Programmiersprache und der Zielplattform des Gruppenprojekts. Integrated Development Environments (IDEs) wie Eclipse oder Visual Studio Code bieten Entwicklern automatisierte Tools wie Code-Insights, Refactorings und Debugging-Werkzeuge. Diese Funktionen erhöhen die Produktivität im Team, da sie schnelleres Schreiben, Anpassen und Debuggen von Code ermöglichen. Die Auswahl einer geeigneten IDE basiert auf der Programmiersprache und der Zielplattform des Gruppenprojekts.
## Vorlesung am 14.11.2023
### Lernziele
- wieso git --> dauerhafter Zugang zu der letzten funktionierenden Version, Zugang zu den verschiedenen Stadien, vergleiche der Veränderungen
- zentralisiertes gegen verteiltes Source Code Managmenent (SCM)
- zentralisiert SCM
pro: jeder commit ist für jeden verfügbar, aktuelle Bearbeiter bekannt, einfaches backup und wiederherstellen, unbegrenzte Ressourcen für das Repository
kontra: zentrale Instanz erforderlich, sperren verhindert paralleles Arveiten, branching und merging sofort sichtbar für alle, keine offline Arbeit
- verteiltes SCM
pro: kein zentraler Server nötig, funktioniert ohne (durchgängigen) Netzwerkzugriff, implizite Backups, offline Arbeit und lokale Experimente bleiben privat
kontra: lokale geschichte ist nicht synchronisiert, keine sicherung gegen gleichzeitige Änderung
- Commit früh, commit oft, halte sie klein und sauber
- Branching
- master Zweig hat keine beschränkung der Lebenszeit
- Develop Zweig ebenso unbegrenzte Lebenszeit, ertser commit ist der Anfang des Projekts
- release Zweig hat eibe limitierte Lebenszeit, wird vom develop branch erstellt, keine neuen funktionen sondern nur reperaturen
- hotfix Zweig kurze Lebeneszeit, wird vom master zweig erstellt, keine neuen funktionen sondern nur (schnelle, heiße) reperaturen
- feature Zweig limitierte Lebenezeit, wird vom develop Zweig ertsellt
- Merge oder Rebase?
Merge
pro: Geschichte zeigt die parallelen arbeiten an, Konfliktlösung muss nur einmal pro merge betrieben werden, bearbeitbare automatische Konfliktlösung
kontra: Komplexer Geschichts graph, Konfliktlösung zwischen den Finalen Versionen
Rebase
pro: "sauberer" graph der Geschichte, Konfliktlösung beim commit --> weniger änderungen auf einmal
kontra: zeigt keine Zeitleiste, jeder commit kann störend sein, erstellt "orphan" commits
### Erkenntnis
Mit Git haben wir ständigen Zugriff auf die letzte funktionierende Codeversion und können Änderungen effizient verfolgen. Ob wir uns für zentrales oder verteiltes Source Code Management entscheiden, hängt von den Projektbedürfnissen ab. Klar definierte Branching-Strategien und das Motto "Commit früh, commit oft" erleichtern die Zusammenarbeit und bringen Ordnung in den Code.
### Wiederholung
Branching in Git ermöglicht eine parallele Entwicklung, indem verschiedene Codeversionen unabhängig voneinander bearbeitet werden können. Feature-Branches dienen der Implementierung neuer Funktionen, während Release-Branches spezifische Entwicklungsstadien markieren. Die Entscheidung zwischen Merge und Rebase beeinflusst, wie Änderungen in den Hauptentwicklungszweig integriert werden.
Loading…
Cancel
Save