Grundlagen Digital Engineering SW3 PDF

Grundlagen Digital Engineering SW3 03.10.2024 TA.BA_GRUNDING.H24, SW3, Folie 1, 03.10.2024  Git Version Control System TA.BA_GRUNDING.H24, SW3, Folie 2, 03.10.2024 Git Ei...

Grundlagen Digital Engineering SW3 03.10.2024 TA.BA_GRUNDING.H24, SW3, Folie 1, 03.10.2024  Git Version Control System TA.BA_GRUNDING.H24, SW3, Folie 2, 03.10.2024 Git Einführung ▶ Git ist das weltweit populärste Version Control System ▶ es ist kostenlos, Open Source, sehr schnell und skalierbar ▶ wurde entwickelt, um den Quellcode des Linux-Kernels zu verwalten ▶ ein Version Control System... ▶ erfasst Änderungen die im Laufe der Zeit an unserem Code vorgenommen wurden ▶ speichert die Änderungen in einer speziellen Datenbank: Repository ▶ in der History lässt sich ermitteln, wer wann was geändert hat und wieso ▶ wenn wir etwas vermasseln, können wir unser Projekt leicht auf einen früheren Stand zurücksetzen TA.BA_GRUNDING.H24, SW3, Folie 3, 03.10.2024 Versionierung ohne Version Control System Ohne Version Control System muss regelmässig das gesamte Projekt in einen Ordner kopiert werden. Dies ist aufwendig, langsam und funktioniert schlecht bei der Zusammenarbeit mit mehreren Benutzern. TA.BA_GRUNDING.H24, SW3, Folie 4, 03.10.2024 Arten von Version Control Systems Es gibt zwei Arten von Version Control System: ▶ zentralisiert ▶ auf dem lokalen PC befinden sich nur die benötigten Daten ▶ für jede Aktion wird eine Verbindung zum zentralen Server benötigt ▶ z.B. Subversion, Azure DevOps Server,... ▶ verteilt ▶ jeder arbeitet mit einem geklonten Repository (Platzbedarf) ▶ Für die meisten Aktionen wird keine Serververbindung benötigt ▶ z.B. Git, Mercurial,... TA.BA_GRUNDING.H24, SW3, Folie 5, 03.10.2024 Git Tools ▶ GIT ▶ https://git-scm.com/downloads ▶ GUI Clients: ▶ https://www.sourcetreeapp.com/ ▶ https://www.sublimemerge.com/ ▶ Visual Studio Code: ▶ https://code.visualstudio.com/ ▶ https://www.gitkraken.com/gitlens ▶ Kommandozeile (Command line) TA.BA_GRUNDING.H24, SW3, Folie 6, 03.10.2024 Git Installation (1/2) Installation unter Linux pi@raspy:~ $ sudo apt install git pi@raspy:~ $ git --Version git version 2.39.5 Installation unter Windows (Installer - siehe vorherige Folie) C:\Users\zajost>git --version git version 2.46.2 TA.BA_GRUNDING.H24, SW3, Folie 7, 03.10.2024 Git Installation (2/2) Es gibt 3 Hierarchiestufen für die Einstellungen: Folgende Einstellungen werden u.a. gespeichert: ▶ Name ▶ E-Mail ▶ Standardeditor ▶ Zeilenumbruch (Line Endings) TA.BA_GRUNDING.H24, SW3, Folie 8, 03.10.2024 Git Einstellungen Die folgenden Einstellungen werden GLOBAL festgelegt: git config --global user.name "Christian Jost" git config --global user.email "[email protected]" git config --global core.editor "code --wait" ▶ --system speichert die Einstellung für alle Benutzer ▶ --global speichert die Einstellung für alle Repos des Benutzers ▶ --local speichert die Einstellung nur für das aktuelle Repo Konfiguration manuell editieren: git config --global -e TA.BA_GRUNDING.H24, SW3, Folie 9, 03.10.2024 Git Line Endings Windows und MacOS/Linux behandeln Zeilenumbrüche unterschiedlich! git config --global core.autocrlf false TA.BA_GRUNDING.H24, SW3, Folie 10, 03.10.2024 Git Repository erstellen Es gibt zwei Möglichkeiten, ein GIT Repository zu erstellen ▶ ein bestehendes Repository klonen (mehr dazu später) ▶ ein neues, leeres Repository erstellen: ▶ leeren Ordner für das Repository erzeugen: mkdir myProject ▶ in den neu erstellten Ordner wechseln: cd myProject ▶ neues Repository im aktuellen Ordner anlegen: git init TA.BA_GRUNDING.H24, SW3, Folie 11, 03.10.2024 Git Workflow (1/4) TA.BA_GRUNDING.H24, SW3, Folie 12, 03.10.2024 Git Workflow (2/4) TA.BA_GRUNDING.H24, SW3, Folie 13, 03.10.2024 Git Workflow (3/4) TA.BA_GRUNDING.H24, SW3, Folie 14, 03.10.2024 Git Workflow (4/4) TA.BA_GRUNDING.H24, SW3, Folie 15, 03.10.2024 Git Workflow (Beispiel) (1/11) Ausgangslage: Staging Area und Arbeitsverzeichnis sind leer TA.BA_GRUNDING.H24, SW3, Folie 16, 03.10.2024 Git Workflow (Beispiel) (2/11) Im Arbeitsverzeichnis werden neue Dateien angelegt TA.BA_GRUNDING.H24, SW3, Folie 17, 03.10.2024 Git Workflow (Beispiel) (3/11) Mittels add Befehl Dateien vom Projektverzeichnis in die Staging Area kopieren TA.BA_GRUNDING.H24, SW3, Folie 18, 03.10.2024 Git Workflow (Beispiel) (4/11) Mittels commit wird einen Snapshot vom Index erstellt TA.BA_GRUNDING.H24, SW3, Folie 19, 03.10.2024 Git Workflow (Beispiel) (5/11) Die Staging Area wird nach dem Commit nicht geleert! TA.BA_GRUNDING.H24, SW3, Folie 20, 03.10.2024 Git Workflow (Beispiel) (6/11) Im Projektverzeichnis wird nun die Datei "file1"geändert TA.BA_GRUNDING.H24, SW3, Folie 21, 03.10.2024 Git Workflow (Beispiel) (7/11) Mit dem add Befehl wird die geänderte Datei in die Staging Area aufgenommen TA.BA_GRUNDING.H24, SW3, Folie 22, 03.10.2024 Git Workflow (Beispiel) (8/11) Mittels commit wird ein neuer Snapshot vom Index erstellt TA.BA_GRUNDING.H24, SW3, Folie 23, 03.10.2024 Git Workflow (Beispiel) (9/11) Datei "file2"wird nicht mehr benötigt und aus dem Projektverzeichnis gelöscht TA.BA_GRUNDING.H24, SW3, Folie 24, 03.10.2024 Git Workflow (Beispiel) (10/11) Mit dem add Befehl wird die Datei aus der Staging Area entfernt TA.BA_GRUNDING.H24, SW3, Folie 25, 03.10.2024 Git Workflow (Beispiel) (11/11) Mittels commit wird ein neuer Snapshot vom Index erstellt TA.BA_GRUNDING.H24, SW3, Folie 26, 03.10.2024 Staging Files (1/6) Es gibt mehrere Möglichkeiten, Dateien in die Staging Area aufzunehmen ▶ Eine einzelne Datei git add file1.txt ▶ mehrere Dateien git add file1.txt file2.txt ▶ mit Hilfe von Mustern git add *.txt ▶ das aktuelle Verzeichnis (rekursiv) git add. TA.BA_GRUNDING.H24, SW3, Folie 27, 03.10.2024 Staging Files (2/6) Mit dem Befehl git status lässt sich die Staging Area überprüfen: d:\myProject>git status On branch main No commits yet nothing to commit (create/copy files and use "git add" to track) Es sind noch keine Dateien im Projektverzeichnis oder in der Staging Area vorhanden! TA.BA_GRUNDING.H24, SW3, Folie 28, 03.10.2024 Staging Files (3/6) Nachdem zwei Dateien zum Projektverzeichnis hinzugefügt wurden, wird nochmals der Befehl Befehl git status ausgeführt: d:\myProject>git status On branch main No commits yet Untracked files: (use "git add..." to include in what will be committed) file1.txt file2.txt nothing added to commit but untracked files present (use "git add" to track) In der Ausgabe wird angezeigt, dass es Dateien (rot markiert) im Projektverzeichnis gibt, die noch nicht in der Staging Area sind. TA.BA_GRUNDING.H24, SW3, Folie 29, 03.10.2024 Staging Files (4/6) Nachdem die Dateien zum Staging Bereich hinzugefügt wurden, sieht die Statusausgabe wie folgt aus: d:\myProject>git add *.txt d:\myProject>git status On branch main No commits yet Changes to be committed: (use "git rm --cached..." to unstage) new file: file1.txt new file: file2.txt Alle Dateien sind nun in der Staging Area (grün markiert). TA.BA_GRUNDING.H24, SW3, Folie 30, 03.10.2024 Staging Files (5/6) Wird eine Datei bearbeitet, die bereits zum Staging Bereich hinzugefügt wurde, so wird sie wieder als modified angezeigt d:\myProject>git status On branch main No commits yet Changes to be committed: (use "git rm --cached..." to unstage) new file: file1.txt new file: file2.txt Changes not staged for commit: (use "git add..." to update what will be committed) (use "git restore..." to discard changes in working directory) modified: file1.txt Mit git add file1.txt kann die veränderte Datei wieder in die Staging Area übernommen werden. TA.BA_GRUNDING.H24, SW3, Folie 31, 03.10.2024 Staging Files (6/6) Um alle Dateien unabhängig vom Status in der Staging Area anzeigen zu lassen, kann der Befehlt git ls-files verwendet werden d:\myProject>git ls-files file1.txt file2.txt TA.BA_GRUNDING.H24, SW3, Folie 32, 03.10.2024 Commit (1/2) Mit dem Commit wird ein Snapshot, d.h. der aktuell Zustand der Staging Area ins Repository gespeichert. d:\myProject>git commit -m "Initial commit" [main (root-commit) 48ddd8d] Initial commit 2 files changed, 2 insertions(+) create mode 100644 file1.txt create mode 100644 file2.txt Mittels -m "message" kann eine Nachricht zum Commit mitgegeben werden. Wird keine Nachricht mitgegeben, so öffnet sich der Standardeditor (z.B. Visual Studio Code oder nano). Es sollte regelmässig committed werden (bei sinnvollen Projektständen). Jeder Commit soll eine logische Einheit darstellen und eine sinnvolle Nachricht beinhalten. TA.BA_GRUNDING.H24, SW3, Folie 33, 03.10.2024 Commit (2/2) Ein Commit beinhaltet folgende Informationen: ▶ eindeutige ID ▶ Nachricht ▶ Datum/Zeit ▶ Autor ▶ den kompletten Snapshot (Dateien/Ordner) Die Daten im Repository werden komprimiert und es werden keine Inhalte doppelt gespeichert. TA.BA_GRUNDING.H24, SW3, Folie 34, 03.10.2024 Datei löschen Um eine Datei zu löschen gibt es zwei Möglichkeiten: ▶ mittels Betriebssystem Befehlen und anschliessendem git add um die Datei auch in der Staging Area zu löschen rm file1.txt git add file1.txt ▶ oder mittels kombiniertem Git Befehl git rm file1.txt Falls mehrere Dateien gelöscht werden sollen, können diese nacheinander aufgelistet werden oder es können Muster wie git rm *.txt verwendet werden. TA.BA_GRUNDING.H24, SW3, Folie 35, 03.10.2024 Datei umbenennen/verschieben Um eine Datei umzubenennen gibt es wie beim Löschen zwei Möglichkeiten: ▶ mittels Betriebssystem Befehlen und anschliessendem git add mv file1.txt file0.txt git add file1.txt file0.txt ▶ oder mittels kombiniertem Git Befehl git mv file0.txt file1.txt d:\myProject>git status On branch main Changes to be committed: (use "git restore --staged..." to unstage) renamed: file1.txt -> file0.txt TA.BA_GRUNDING.H24, SW3, Folie 36, 03.10.2024 Dateien ignorieren (1/3) Während dem Entwicklungsprozess fallen Logdaten und andere Dateien an, die nicht im Git Repository gespeichert werden sollen. Es soll beispielsweise folgender logs/ Ordner ausgeschlossen werden: d:\myProject>git status On branch main Untracked files: (use "git add..." to include in what will be committed) logs/ Dazu wird typischerweise im Root-Verzeichnis des Repositories eine Datei mit dem Namen.gitignore und folgendem Inhalt erstellt: d:\myProject>cat.gitignore logs/ In der Datei können untereinander weitere Dateien und oder Ordner hinzugefügt. Es können auch Muster verwendet werden. TA.BA_GRUNDING.H24, SW3, Folie 37, 03.10.2024 Dateien ignorieren (2/3) Wird der Status geprüft, so wird der logs/ Ordner nicht mehr angezeigt: d:\myProject>git status On branch main Untracked files: (use "git add..." to include in what will be committed).gitignore nothing added to commit but untracked files present (use "git add" to track) Hingegen wird nun die.gitignore Datei angezeigt, die wir noch ins Repository aufnehmen müssen: d:\myProject>git add.gitignore d:\myProject>git commit -m "added logs/ to.gitignore" [main b1f3304] added logs/ to.gitignore 1 file changed, 1 insertion(+) create mode 100644.gitignore TA.BA_GRUNDING.H24, SW3, Folie 38, 03.10.2024 Dateien ignorieren (3/3) Dateien die bereits im Repository sind und erst später der.gitignore Datei hinzugefügt werden, entfernt Git nicht automatisch aus der Staging Area. Wurde beispielsweise versehentlich der Ordner bin/ hinzugefügt, so fügt man ihn zur.gitignore Datei hinzu und löscht den Ordner wie folgt aus der Staging Area: git rm --cached -r bin/ Anschliessend die veränderte.gitignore zur Staging Area hinzufügen und committen: git add.gitignore git commit -m "Unnecessary bin folder removed" Vordefinierte Liste: github.com/github/gitignore TA.BA_GRUNDING.H24, SW3, Folie 39, 03.10.2024 Centralized vs. Distributed TA.BA_GRUNDING.H24, SW3, Folie 40, 03.10.2024 Centralized Workflow (1/4) Bei Git besitzt jeder Entwickler eine lokale Kopie des gesamten Repositories. Statt untereinander die Repositories zu synchronisieren, wird dies über ein zentrales Repository (grün dargestellt) gemacht. TA.BA_GRUNDING.H24, SW3, Folie 41, 03.10.2024 Centralized Workflow (2/4) Zu Beginn holt sich jeder Entwickler eine Kopie vom zentralen Repository, d.h. das Repository wird geklont: Anschliessend besitzt jeder Entwickler eine lokale Kopie vom zentralen Repository: TA.BA_GRUNDING.H24, SW3, Folie 42, 03.10.2024 Centralized Workflow (3/4) Die Entwickler committen ihre Arbeit im lokalen Repository. Um die Änderungen auch mit den anderen Entwicklern zu teilen, werden die Änderungen auf das zentrale Repository übertragen (push): Anschliessend können die anderen Entwickler die Änderungen mittels pull in ihr lokales Repository übernehmen TA.BA_GRUNDING.H24, SW3, Folie 43, 03.10.2024 Centralized Workflow (4/4) Beim Holen der Änderungen vom zentralen Repository kann es zu Konflikten mit lokalen Dateien kommen, die ebenfalls verändert wurden. Diese Konflikte müssen zuerst gelöst werden, bevor die eigene Arbeit zurück ins zentrale Repository übertragen werden kann: TA.BA_GRUNDING.H24, SW3, Folie 44, 03.10.2024