@ -101,3 +101,124 @@ Der Prozess des Debuggings, bei dem man Fehler in einem Programm oder Software i
Eine IDE (Integrated Development Environment) ist eine Software, die Entwicklern bei der Erstellung, Bearbeitung, dem Testen und der Fehlerbehebung von Code unterstützt und somit eine zentrale Umgebung bietet, in der Benutzer ihren Code effizient schreiben und testen können. Eine IDE bietet in der Regel viele nützliche Funktionen, wie beispielsweise eine integrierte Textbearbeitung, Compiler oder Interpreter für verschiedene Programmiersprachen, Debugging-Tools und automatische Codevervollständigung. Beliebte Beispiele für IDEs sind Visual Studio, Eclipse und IntelliJ.
Eine IDE (Integrated Development Environment) ist eine Software, die Entwicklern bei der Erstellung, Bearbeitung, dem Testen und der Fehlerbehebung von Code unterstützt und somit eine zentrale Umgebung bietet, in der Benutzer ihren Code effizient schreiben und testen können. Eine IDE bietet in der Regel viele nützliche Funktionen, wie beispielsweise eine integrierte Textbearbeitung, Compiler oder Interpreter für verschiedene Programmiersprachen, Debugging-Tools und automatische Codevervollständigung. Beliebte Beispiele für IDEs sind Visual Studio, Eclipse und IntelliJ.
### Kritik
### Kritik
___
## SU 04 (14.11.2023)
### Lernziel
- Source-Code-Management (SCM)
- Permanenter Zugang zum letzten Arbeitszustand
- Zugang zu den verschiedenen Zuständen des Codes
- Vergleich von Änderungen in Laufe der Zeit/Unterschiede zws. verschiedenen Funktionen oder Entwicklungszweigen
- optimiert für minimalen Festplattenspeicherbedarf
- bei Bearbeitung des Projekts wissen es alle und keine Anderen können daran Arbeiten
- leichte Backups und Wiederherstellung
- unendliche Ressource für das Repository
- Nachteile
- zentrale Instanz erforderlich
- "locking" verhindert paralleles Arbeiten
- Änderungen am Branch und Zusammenführung sofort für alle sichtbar
- keine Offline-Arbeit möglich
- Verteiltes SCM
- Vorteile
- kein zentraler Server erforderlich
- mehrere remotes möglich
- funktioniert ohne (permanente) Netzwerkverbindung
- implizierte Backups
- offline Arbeit (eigene/lokale 'Experimente' bleiben privat')
- Nachteile
- lokaler Verlauf ist nicht synchron
- kein Schutz gegen gleichzeitige Änderungen
- Git Konzept
- basiert auf Veränderungen und nicht auf Dateien
- Commits durch SHA geschützt
- Branches sind Labels für Commits
- Staging Area
- Commits
- sollten klein sein (Konflikte leichter lösen (automatisch und manuell)
- "cherry pick" einfacher (Änderung auswählen und in anderem Zweig übernehmen)
- Grandularität der Dokumentation/Verlaufs
- Änderungen im Verlauf leicher zu finden
- sollte durchgeführt werden, wenn gesamtes Projekt erfolgreich kompiliert und Test bestanden wurde.
- es sollte committet werden, wenn...
- ...eine einzelne neue Funktionalität abgeschlossen ist
- ...ein einzelner Refactoring-Schritt abgeschlossen ist
- ...nachdem Merge- oder Rebase-Konflikte gelöst wurden
- Branching
- develop
- unbegrenzte Lebensdauer
- erster Commit merkiert Start des Projekts (immer in auslieferbaren Zustand)
- jeder Entwickler kann fertiges Feature in Zweig einfügen (idealerweise durch "build-server")
- release
- endliche Lebensdauer während "feature freeze"
- entsteht aus develop
- kein Hinzufügen neuer Features (nur Fixes)
- jeder Entwickler kann Commits durchführen
- Release-Kandidaten werden getaggt
- Mergen in develop durch Build-Server (mindestens "RC"-Tags)
- master
- unbegrenzte Lebensdauer
- verwaltet von dedizierten verantwortlichen Committer
- entsteht aus initialen Commit
- jeder Commit bezieht sich auf ein Ereignis, bei dem Version verschickt wird
- Commits mit Versionsnummer getaggt
- direkte Commits nicht erlaubt, nur Merges (--no-ff) von Release- oder Fix-Zweigen akzeptiert
- hotfix
- kurze Lebensdauer
- entsteht aus master
- jeder Entwickler kann Commits durchführen aber keine neuen Features hinzufügen (nur "hot" Fixes vornehmen)
- Mergen in develop und release durch Build-Server (wenn vorhanden)
- feature
- begrenzte Lebensdauer
- entsteht aus develop
- sollte auf develop basieren und neue Commits integrieren
- jeder Entwickler kann Commits durchführen, sollte aber nur zugewiesener Entwickler
- Merge
- Vorteile
- parallele Arbeit durch Verlauf visualisiert
- Konfliktlösung nur einmal pro Menge
- Konfiguration automatische Konfliktlösung
- Nachteile
- Verlauf zu komplex aussehen
- Konflikte zwischen endgültigen Zuständen
- Bevorzugt, wenn:
- aktuell in develop oder master
- Verlauf mit Zeitleiste synchron bleiben
- aktueller Branch bereits gemerged
- Rebase
- Vorteile
- Verlauf sieht sauberer aus
- Konfliktlösung pro Commit (automatische und manuelle Konfliktlösung einfacher)
- Nachteile
- Verlauf kann nicht in einer Zeitleiste dargestellt werden
- jeder Commit kann konfliktreich sein
- Entstehung verwaiste Commits
- Bevorzugt, wenn:
- Arbeiten an unfertigen Feature (noch nicht in alle Branches gemerged)
- saubere Verlauf gewünscht
- Branch mit vielen Commits
- ein "squash-commit" vorzubereiten ist
### Erkenntnis
Sowohl das Source-Code-Management, als auch das Konzept von Git werden wichtige Elemente des Gruppenprojekts sein und so gut wie möglich eingebracht. Für eine gute und übersichtliche Struktur sind die Git Branches essenziell und werden auf alle Fälle genutzt.
### Wiederholung
Git Branches entsprechen Zweigen, repräsentieren Zeitlinien von Code-Backups und erlauben das Betreiben von Source-Code-Management. "Master", "develop" und "feature" sind ein paar Standards der typischen Branches und haben verschiedene Funktionen, wie die Nutzung für neue Features oder Erschaffen von neuen Zweigen.
fdai8040
1 year ago