Versionsverwaltung & Git


:dart: Lernziele

  • Studierende wissen was Versionsverwaltung ist & warum sie wichtig/hilfreich ist
  • Studierende können mit Git über die Kommandozeile und über VS Code arbeiten
  • Studierenden können Repositories auf github anlegen und verwalten

Git

  • Git [ɡɪt] ist eine freie Software zur verteilten Versionsverwaltung von Dateien, die durch Linus Torvalds initiiert wurde
  • Neben der Versionierung ist inzwischen ein Ökosystem zur Entwicklung und der Pflege von Software gewachsen
  • Damit wir git nutzen können, müssen wir es zunächst hier installieren

Git

Begriffe

  • GitHub ist eine Website (von Microsoft) auf der man Code speichern und veröffentlichen kann. Dient als Backup, Visitenkarte uvm. Es gibt diverse andere Anbieter
  • Git ist die dahinterliegende Technologie zur Verwaltung von Quellcode
  • Ein Repository oder Repo ist das Projektverzeichnis, in dem meist mehrere Dateien liegen.

bg right:40% w:480

Bild: https://xkcd.com/1597/


Versionskontrolle beim alleinigen Arbeiten

  • Mit Versionskontrollsoftware können Änderungen mit Notizen versehen werden → entkoppelt Dateinamen und Version
  • Es kann jederzeit zu einer Vorversionen zurückgekehrt werden

Beispiel ohne Versionsverwaltung

  • Version wird in Dateinamen festgehalten
  • main.py
  • main2.py
  • main2_test.py

Beispiel mit Versionsverwaltung

  • Version wird in commits mit einer eindeutigen ID festgehalten
  • main.py (8e3ae40)
  • main.py (8c22176)
  • main.py (7e01f48)

Git - Commits & Commit-Messages

  • Jede Version wird in einem commit festgehalten
  • Zu jedem Commit gehört eine Nachricht, die die Änderung zur letzten Version beschreibt


Git - Projektstatus

  • Durch Git bleibt der Projekt-Status konsistent → auch wenn mehrere Dateien von der Änderung betroffen sind

Beispiel

  • Anwendung: Berechnung des Mittelwertes aus der letzten Vorlesung
  • Version 1: main.py und calc_mean.py als Modul
  • Version 2: main.py und calc_mean.py als Modul im Package statistics

#Version 1
.
├── calc_mean.py
└── main.py --> from calc_mean import mean

#Version 2
.
├── statistics
│   └── calc_mean.py
└── main.py --> from statistics import calc_mean
- Code in main.py & Ordnerstruktur und Inhalt von calc_mean.py haben sich gemeinsam & konstisten geändert


Git - Projektstatus

  • Mehrere Alternativen könne gleichzeitig verfolgt werden → wenn z.B. ein neues Feature getestet werden muss → Verzweigungen bzw. Branches im Projekt

  • Ansatz: "move fast and break things" → funktioniert nur, weil man immer ein funktionsfähiges Backup hat


Git - Branches

  • Verzweigungen eines Projekts
  • An einem bestimmten Zeitpunkt zweigt das Projekt ab → hier mit dem Namen feature_x
  • Ist das Feature fertig entwickelt und erfolgreich getestet, wird es wieder mit dem originalen Projektstamm master od. main gemerged

invert


Git - Branches

  • Es gibt immer eine stabile (funktionierende) Version → master oder main-Branch
  • Neue Idee, Änderungen, Fehlerbehebungen werden in separaten Branches entwickelt & getestet (z.B.: feature_x)
  • Sobald die Änderungen fertig sind, werden sie in den main-Branch gemerged - → hier gibt es eine Differenz zw.:
  • unveränderten Dateien im main Branch
  • veränderten Dateien im feature_x Branch → müssen durch eine bewusste Entscheidung beseitigt werden

Zu merken:

  • Der Prozess:
  • neuen Branch erstellen
  • Änderungen durchführen & testen
  • Änderungen in den main-Branch mergen

→ soll für jedes Feature durchgeführt werden!


github - Plattform für Git

  • github.com ist eine zu Microsoft gehörende Online-Plattform zur Versionsverwaltung von Softwareprojekten mittels Git
  • Stellt eine zentrale Plattform dar → Features für Projektmanagement, CI/CD, Wiki, Copilot, etc.

✅ Anlegen eines github-Accounts

  • Wir werden in weiterer Folge einen github-Account benötigen
  • mit der "@mci4me.at"-Adresse können Sie sich ein kostenlosen GitHubPro Student-Account anlegen
  • → muss evtl. noch durch Dokument (Studierendenausweis, etc.) bestätigt werden

Git - Beispiel

  • Wir wollen nun in einem Beispiel den gesamten üblichen Git-Workflow durchlaufen:
  • Anlegen eines neuen Projekts
  • Erstellen eines Git-Repository
  • Erstellen & hinzufügen einer Datei
  • Commit der Änderungen
  • Anderen Branch erstellen
  • Dazu sehen wir uns Schritt für Schritt die Architektur von Git an

:repeat: Begriffe

  • Repositories sind im Allgemein Projektordner incl. .git Dateien → alles darin wird von Git versioniert
  • Commit ist ein Snapshot/eine Version des Projekts zu einem bestimmten Zeitpunkt
  • Branch ist eine Verzweigung des Projekts, um z.B. neue Features zu entwickeln

Architektur von Git

Entwicklungsumgebung → auf dem eigenen PC

  • Working directory: auf dem PC an dem am Code gearbeitet wird
  • Staging area: "Vorschau" für commit → git add
  • Local repository: Repository in dem Git die Änderungen verwaltet → git commit

Server → üblicherweise github

  • Remote repository: Teilt die Änderungen mit der Umwelt → git push

width:600

Quelle aller folgenden Bilder: Quelle


🤓 Beispiel in der Git Bash

  • Anlegen eines neue Projekts

    $ mkdir project_1
    $ cd project_1/
    

  • Erstellen eines neuen Git-Repository

    $ git init
    Initialized empty Git repository in /project_1/.git/
    


  • Erstellen einer Datei, Hinzufügen zum Repository und Commit
    $ nano main.py
    $ git add .
    $ git commit -m "created first file"
    
  • Sollte beim ersten commit noch kein Name und Email-Adresse konfiguriert sein, wird dies in der Shell mit einer Fehlermeldung angezeigt
  • Für die globale git-Installation geschieht dies mit
    $ git config --global user.name "Max Mustermann"
    $ git config --global user.email "max@mustermann.at"
    
    → verwenden Sie hier die gleichen Einstellungen wie für github

🤓 Beispiel in der Git Bash

  • Das lokale Repository ist nun initialisiert → alle von Git erstellten Dateien sind im versteckten Verzeichnis .git abgelegt → wird dieses gelöscht ist das Repository nicht mehr verwendbar
  • Die Datei main.py ist im Repository
  • Die Staging Area ist leer und es gibt keine Änderungen

Beispiel

  • Anzeigen des verstecken .git Verzeichnis
    $ ls -la
    total 9
    drwxr-xr-x 1 jlhuber 1049089  0 Oct 10 09:15 ./
    drwxr-xr-x 1 jlhuber 1049089  0 Oct 10 09:14 ../
    drwxr-xr-x 1 jlhuber 1049089  0 Oct 10 09:16 .git/
    -rw-r--r-- 1 jlhuber 1049089 15 Oct 10 09:15 main.py
    

  • Überprüfen des Status auf Änderungen
    $ git status
    On branch master
    nothing to commit, working tree clean
    

Architektur von Git - Änderungen im Working Directory

  • Was passiert wenn sich Dateien im Working Directory ändern?
  • → passiert durch normales Speichern der Datei in z.B. VSCode oder nano
  • Es gibt zwei Arten von Dateien im Working Directory
  • Tracked: Dateien, die git bereits kennt (nach git add)
  • Untracked: Dateien, die git (noch) nicht kennt

width:650


Architektur von Git - Updaten des Local Repository

  • Wir wollen Änderungen von Working Directory in Local Repository übernehmen → egal ob ob Dateien Tracked oder Untracked sind
  • Git erkennt automatisch, welche Dateien seit dem letzten Commit geändert wurden → werden der Staging Area mit git add hinzugefügt
  • Commit fasst zusammen-gehörende Änderungen zusammen

width:650


🤓 Beispiel in der Git Bash

  • Anpassen der Datei & Status überprüfen
    $ nano main.py
    $ git status
    On branch master
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git restore <file>..." to discard changes in working directory)
            modified:   main.py
    
  • Änderungen zu Staging Area hinzufügen
    $ git add .
    warning: LF will be replaced by CRLF in main.py.
    The file will have its original line endings in your working directory
    
    $ git status
    On branch master
    Changes to be committed:
      (use "git restore --staged <file>..." to unstage)
            modified:   main.py
    
  • Änderungen committen
    $ git commit -m "made it print hello world"
    [master d16ac29] made it print hello world
     1 file changed, 1 insertion(+), 1 deletion(-)
    

Beispiel in der Git Bash

  • Wir können uns einen Überblick über alle vergangenen Commits verschaffen
  • Anzeigen der Commit-History
    $ git log
    commit d16ac298c8bebfbee72520da0a64b0fa2690845f (HEAD -> master)
    Author: jhumci <julian.huber@mci.edu>
    Date:   Tue Oct 10 09:20:55 2023 +0200
    
        made it print hello world
    
    commit 22cde1b198d304a8eb428f8905ee8d8304316fbd
    Author: jhumci <julian.huber@mci.edu>
    Date:   Tue Oct 10 09:16:18 2023 +0200
    
        created first file
    
  • Es werden Commit-Hash (ID), Autor, Datum und Commit-Message angezeigt

Beispiel in der Git Bash

  • Wir wollen einen neuen Branch erstellen und dorthin wechseln
  • In git bash wird in runden Klammern der aktuelle Branch angezeigt

  • Erstellen und Wechsel zu neuem Branch

    jlhuber@4LAP104500JLH MINGW64 /h/project_1 (master)
    $ git branch add_variable
    
    $ git checkout add_variable
    Switched to branch 'add_variable'
    


🤓 Beispiel in der Git Bash

  • Anpassen der Datei
    jlhuber@4LAP104500JLH MINGW64 /h/project_1 (add_variable)
    $ nano main.py
    
    $ git add .
    warning: LF will be replaced by CRLF in main.py.
    The file will have its original line endings in your working directory
    
    $ git commit -m "added a variable to the print statement"
    [add_variable bc6fc8f] added a variable to the print statement
     1 file changed, 2 insertions(+), 1 deletion(-)
    

🤓 Beispiel in der Git Bash

  • Commit-History ändert sich mit dem Branch-Wechsel → es wird nur die Historie des aktuellen Branches angezeigt
  • Anzeigen der Commit-History
    $ git log
    commit bc6fc8f85adf2716bfc738c20a46c1ccc665e29e (HEAD -> add_variable)
    Author: jhumci <julian.huber@mci.edu>
    Date:   Tue Oct 10 09:24:27 2023 +0200
    
        added a varibale to the print statement
    
    commit d16ac298c8bebfbee72520da0a64b0fa2690845f (master)
    Author: jhumci <julian.huber@mci.edu>
    Date:   Tue Oct 10 09:20:55 2023 +0200
    
        made it print hello world
    
    commit 22cde1b198d304a8eb428f8905ee8d8304316fbd
    Author: jhumci <julian.huber@mci.edu>
    Date:   Tue Oct 10 09:16:18 2023 +0200
    
        created first file
    

Beispiel in der Git Bash

  • Wir wollen nun in den master-Branch wechseln und die Änderungen von add_variable in master mergen

  • Wechsel zu Master-Branch

    jlhuber@4LAP104500JLH MINGW64 /h/project_1 (add_variable)
    $ git checkout master
    Switched to branch 'master'
    


🤓 Beispiel in der Git Bash

  • Merge von add_variable in master
    jlhuber@4LAP104500JLH MINGW64 /h/project_1 (master)
    $ git merge add_variable
    Updating d16ac29..bc6fc8f
    Fast-forward
     main.py | 3 ++-
     1 file changed, 2 insertions(+), 1 deletion(-)
    $ nano main.py
    
  • VS-Code unterstützt uns in Zukunft dabei, dennoch ist es hilfreich die wichtigsten Befehle zu verstehen
  • Öffnen Sie das Verzeichnis nun in VS Code, wählen Sie die Datei main.py aus und zeigen Sie die Zeitachse an

:nerd_face: Branching in Git

  • Branches sind sehr mächtig, können aber auch zu Probelemen führen wenn sie nicht richtig gehandhabt werden
  • Wir haben nur die beiden folgenden Kommandos kennengelernt:
  • git branch <branch-name>: Erstellt einen neuen Branch
  • git checkout <branch-name>: Wechselt zu einem Branch
  • Um alle weitern Befehle zu erproben kann das Online-Tool Learn Git Branching verwendet werden

Architektur von Git - Klonen eines Repositories

  • häufig ist Ausgangspunkt ein bestehendes Repository → soll kopiert werden um daran fortzusetzen → git clone
  • das Remote Repository landet an zwei Orten
  • Working directory
  • Local repository

width:600


Beispiel in der Git Bash

  • Wir wollen nun ein erstes Repository klonen:
  • Repository: test_git_shell → https://github.com/jhumci/test_git_shell
  • öffentliches Repository mit zwei Branches

  • Klonen des Repositories

    $ git clone https://github.com/jhumci/test_git_shell
    Cloning into 'test_git_shell'...
    remote: Enumerating objects: 68, done.
    remote: Counting objects: 100% (68/68), done.
    remote: Compressing objects: 100% (53/53), done.
    remote: Total 68 (delta 30), reused 29 (delta 5), pack-reused 0 (from 0)
    Receiving objects: 100% (68/68), 12.64 KiB | 1.40 MiB/s, done.
    Resolving deltas: 100% (30/30), done.
    


  • Inhalt des Repository überprüfen
    $ cd test_git_shell/
    $ ls -la
    total 19
    drwxr-xr-x 1 mtpanny 1049089    0 Nov  5 14:04 .
    drwxr-xr-x 1 mtpanny 1049089    0 Nov  5 14:03 ..
    drwxr-xr-x 1 mtpanny 1049089    0 Nov  5 14:04 .git
    -rw-r--r-- 1 mtpanny 1049089   25 Nov  5 14:03 .gitignore
    -rw-r--r-- 1 mtpanny 1049089 1088 Nov  5 14:04 LICENSE.md
    drwxr-xr-x 1 mtpanny 1049089    0 Nov  5 14:03 data
    -rw-r--r-- 1 mtpanny 1049089   67 Nov  5 14:03 hello_world.py
    -rw-r--r-- 1 mtpanny 1049089  403 Nov  5 14:03 make_primes.py
    -rw-r--r-- 1 mtpanny 1049089 2808 Nov  5 14:03 readme.md
    

Beispiel in der Git Bash

  • Unabhängig von der Art des Softwareprojekts gibt es einige Dateien, die in jedem Projekt vorhanden sein sollten

Wichtige Dateien für Git

  • .gitignore: Listet alle Dateien und Ordner auf, die nicht mittels git geteilt werden sollen → :warning: muss zu Beginn des Projekts erstellt werden!
  • :nerd_face: .gitattributes: Konfigurationsdatei für git

Allgemeine wichtige Dateien

  • readme.md: Textdatei mit Beschreibung & Erklärung des Projekts
  • LICENSE oder LICENSE.md: Lizenzdatei für das Projekt

Architektur von Git - gitingore

  • .gitignore-Datei ist eine Textdatei, die Dateien und Ordner enthält, die von Git ignoriert werden sollen
  • Üblicherweise wollen wir nur die Dateien und Ordner im Repository haben, die für das Projekt relevant sind und NICHT automatisch generiert werden
  • .DS_Store-Dateien auf Mac
  • .vscode-Ordner
  • __pycache__-Ordner
  • .venv-Ordner
  • *.pyc-Dateien
  • etc.
  • Für Projekte in den meisten Programmiersprachen gibt es bereits vorgefertigte .gitignore-Dateien → github/gitignore → jeweilige Datei herunterladen, in das Projekt kopieren und in .gitignore umbenennen

Architektur von Git - Updaten des lokalen Repository

  • Zum Zeitpunkt des Klonens ist das lokale Repository auf dem neusten Stand → wir werden aber nicht automatisch über Änderungen im Remote Repository informiert
  • Bevor lokal weiter gearbeitet wird immer mit git fetch die aktuellen Änderungen abholen:
  • das Local Repository wird auf den neusten Stand gebracht
  • Änderungen im eigenen Working Directory bleiben unangetastet

width:600


:nerd_face: Beispiel in der Git Bash

  • Lokalen Stand des Repository überprüfen
    $ git log
    commit a0d6f07bd29595e9bbe346acf78322489851e423 (HEAD -> master)
    Author: Julian Huber <94922106+jhumci@users.noreply.github.com>
    Date:   Wed Feb 7 08:54:08 2024 +0100
        Update readme.md
    commit c303672b3a9215a69b07b48a49833e53b872c017
    Author: jhumci <julian.huber@mci.edu>
    Date:   Wed Jul 12 10:12:20 2023 +0200
        new tasks
    

:nerd_face: Beispiel in der Git Bash

  • Änderungen von Remote Repository holen → git fetch
  • Änderungen zu aktuellem lokalen Stand überprüfen
    $ git log HEAD..origin/master
    commit 982a416434965dcf9a4956824c22a105782662b4 (origin/master, origin/HEAD)
    Author: Julian Huber <94922106+jhumci@users.noreply.github.com>
    Date:   Mon Apr 8 10:01:23 2024 +0200
        Update readme.md
    commit 9602dce8ff2ba72b9900289525f336b57b85d497
    Author: Julian Huber <94922106+jhumci@users.noreply.github.com>
    Date:   Mon Apr 8 08:13:51 2024 +0200
        Update readme.md
    commit c009fda83f2d19c6040bc70a5b527dbc1efa9963
    Author: Julian Huber <94922106+jhumci@users.noreply.github.com>
    Date:   Wed Feb 7 08:55:48 2024 +0100
        Update .gitignore
    commit 29893946a2cbdfa7e80ac771af428805d2be91fc
    Author: Julian Huber <94922106+jhumci@users.noreply.github.com>
    Date:   Wed Feb 7 08:55:21 2024 +0100
        Update readme.md
    

Architektur von Git - Pulling

  • Nachdem die Änderungen abgeholt wurden, können sie in das eigene Working Directory eingebaut werden → git merge
  • Üblicherweise wollen wir beide Schritte kombinieren
  • git fetch: Holen der aktuellen Änderungen
  • git merge: Einbauen der Änderungen → git fetch + git mergegit pull

width:600


Architektur von Git - Updaten des Remote Repository

  • :repeat: Um Änderungen aus dem Working Directory ins Local Repository zu übertragen → git add + git commit
  • Änderungen im Local Repository können auch ins Remote Repository übertragen werden → git push

width:750


Git - Umgang mit Unterschieden

  • Änderungen des Working Directory gegenüber dem letzten Commit können mit git diff angezeigt werden
  • + In der Datei ist Code hinzugekommen
  • - Code wurde aus der Datei entfernt

width:950


🏆 Sakai-Aufgabe 4: VS Code mit Github-Account

  • Installieren Sie Visual Studio Code
  • Öffnen Sie den Ordner, in dem Sie den Code aus Sakai-Aufgabe 3 gespeichert haben über File -> Open Folder
  • Wählen Sie Terminal -> New Terminal und erstellen Sie ein PowerShell-Terminal und geben Sie erneut python main.py ein. Sofern dies zu einem Fehler führt, versuchen Sie die Fehlermeldung zu verstehen und zu beheben, falls das nicht gelingt, kopieren Sie die Fehlermeldung in die Sakai-Aufgabe 4
  • Gehen Sie auf das Account-Symbol in der unteren linken Ecke und wählen Sie Sign in with Github ...

  • Installieren Sie git auf Ihrem Rechner: git-scm.com
  • Nach einem Neustart von Visual Studio Code, sollten Sie in der Lage sein, nun auch eine git-bash-Terminal zu öffnen
  • Führen Sie darin folgende Befehle aus
    • Ersetzen Sie "Ihr Name" und "Ihre E-Mail" durch Ihren github account
    • pwd zeigt Ihnen den absoluten Pfad zum Arbeitsverzeichnis
    • git --version zeigt Ihnen die installierte git-Version
    • git config --global user.name "Ihr Name auf github"
    • git config --global user.email "Ihre E-Mail von github"
    • git config --list
  • kopieren Sie das Ergebnis oder Fehlermeldungen ebenfalls in die Sakai-Aufgabe 4 Sofern alles Funktioniert hat, schreiben Sie einfach nur ok in die Abgabe, ansonsten posten Sie die Fehlermeldung

Appendix: Ausführliches Beispiel mit VS Code

Julian Huber & Matthias Panny


Ausführliches Beispiel mit VS Code

Übung: Beispiel Versionsverwaltung

  • Voraussetzung ist ein eigener Github Account
  • Legen Sie ihre eigene Kopie des Verzeichnisses an https://github.com/jhumci/IntroGitHub Fork (oben rechts)
  • nun haben Sie eine eigene Kopie des Projektes
  • (dies ist kein Branch sondern eine Kopie des Projekts mit eigenem main-Branch)

width:1100


Ausführliches Beispiel mit VS Code

Übung: Klonen des Repository

  • In einem neuen Fenster in VS Code können Sie das Projekt nun clonen
  • Zunächst wird Sie git nach Ihrem Nutzernamen und Passwort fragen

width:1100


Ausführliches Beispiel mit VS Code

Übung: Repository auswählen

  • Oben in VS Code öffnet sich ein Auswahlfenster, in dem Sie das zu clonende Projekt auswählen können
  • Alternativ können Sie auch eine Kommandozeile öffnen und ein Projekt mit dem Befehl herunterladen git clone <URL-Projekt>

width:1100


Ausführliches Beispiel mit VS Code

Übung: Geöffnetes Projekt

  • Sie sehen nun, dass das Repository/Projekt nur eine Datei enthält
  • Oben rechts, im mittleren Fenster (Lupe) können Sie die Vorschau öffnen der Markdown Datei öffnen

width:1100


Ausführliches Beispiel mit VS Code

Übung: Neuer Branch

  • ganz links lässt sich das git-Menü (verzweigte Pfeile) öffnen
  • Nun können Sie im Menü (im linken Fester rechts oben) einen neuen Branch anlegen

width:1000


Ausführliches Beispiel mit VS Code

Übung: Änderungen im Working Directory

  • Geben Sie dem Branch einen Namen (z.B. Ihren eigenen)
  • Ändern Sie den Namen in der Markdown Datei
  • Speichen Sie die Änderung (nun ist die Änderung im Working directory wirksam)
  • Öffnen Sie dein Terminal ('.../Gitausgabe anzeigen') und überprüfen Sie den Status von Git (git status)

width:850


Ausführliches Beispiel mit VS Code

Übung: Änderungen im Working Directory

  • Sie sehen nun, dass eine Datei verändert wurde (modified), aber noch nicht in den Branch übernommen wurde (gestaged)

width:1100


Ausführliches Beispiel mit VS Code

Übung: Übernehmen von Änderungen in einem Commit

  • Um eine Änderung im Branch zu comitten vergeben sie einen commit-name und und bestätigen Sie mit dem ✔️
  • gegen Sie erneut git status ein
  • Die Antwort bestätigt Ihnen, dass nun alles im aktuellen Branch erfasst ist
    On branch Christoph
    nothing to commit, working tree clean
    

width:800


Ausführliches Beispiel mit VS Code

Übung: Veröffentlichen eines Commits

  • veröffentlichen Sie den Branch und prüfen Sie auf der Github Website, dass der Branch nun auch dort verfügbar ist
  • Der Befehl, der im Hintergrund abläuft heißt git push

width:1100


Ausführliches Beispiel mit VS Code

Übung: Wechseln zwischen Branches

  • Unten links können Sie jederzeit zwischen ihren Branches wechseln
  • Hier sind sowohl remote als auch lokale Branches sichtbar durch git fetch können sie diese synchron halten
  • Ihre Änderungen bleiben dabei im jedem Branch erhalten
  • Wechseln Sie zwischen den Branches zurück auf den Main-Branch

width:1100


Ausführliches Beispiel mit VS Code

Übung: Umgang mit Differenzen

  • Fügen Sie in beiden Branchens einen unterschiedlichen Nachnamen hinzu und comitten und veröffentlichen Sie beide Änderungen

width:1100


Ausführliches Beispiel mit VS Code

Zusammenführen von Branches (Mergen)

  • Wechseln Sie zu Branch Main
  • Wählen Sie 'Branch/ Branch zusammenführen/'
  • Nun tritt ein Konflikt auf, da beide Dateien unabhängig voneinander geändert wurden

width:1100


Ausführliches Beispiel mit VS Code

Übung: Zusammenführen von Branches (Mergen)

  • Sie müssen nun Entscheiden, ob sie den Current Change (aus dem Branch in dem Sie sind) oder in Incomming Change aus dem zweiten Branch behalten
  • Akzeptieren Sie eine der Versionen und comitten und pushen Sie die Änderungen
  • Erstellen Sie anschießend einen neuen Branch für ihre nächste Veränderung

width:1100


Ausführliches Beispiel mit VS Code

Übung: Überprüfen des Erfolgs auf github

  • Nachdem Sie Ihre Änderungen gepusht haben, können Sie diese auch auf Github nachvollziehen
  • Hier sollten nun beide Branches zu finden sein

width:1000