Update from Fork

Das eigene Repoitory auf den aktuellen Stand bringen
Autor:in

Nicola Jordan, chatGPT

Veröffentlichungsdatum

28. August 2023

Eigene, interaktive Webseite gestalten

Ziel

Das übergeordnete Ziel ist das Datenmodell aus der Open-Air-Übung in “die” Webseite Einzupflegen.

Vorbedingungen

Du besitzt ein Repo auf gitlab.ost.ch und dieses hast du von unserem Hauptrepo geforkt. Unser Repo nennt man auch upstream.

Kurzfassung

  1. Code vom upstream updaten und den richtigen Branch wählen (diese Anleitung)
  2. Webseite umsetzen (nächstes “Kapitel”)

Wir möchten den neuesten Code holen (weil wir, die den Upstream pflegen, noch Updates gemacht haben während dem Kurs) vom Upstream auf unser Repo einpflegen.

Tools, die wir in diesem Teil verwenden werden (siehe erster Übungsteil für die Installation):

Auf dem Rechner:

  • Docker
  • git
  • python
  • VSCode

Mit Docker betrieben:

  • Postgres
  • pgAdmin
  • Vorlage einer Webseite mit WebAssembly/WASM damit Python im Browser genutzt werden kann

Aktualisieren eines geforkten Git Repositories auf GitLab

Um dein geforktes Repository auf den neuesten Stand des ursprünglichen (upstream) Repositories zu bringen, führe die folgenden Schritte aus:

1. Remote Repository hinzufügen

Zuerst solltest du sicherstellen, dass du das Original-Repository als “upstream” hinzugefügt hast. Falls nicht, füge es mit diesem Befehl hinzu:

git remote add upstream https://gitlab.ost.ch/vorkurs-i/datenmodelle/uebungen.git

Dieser Schritt brauchst du nur einmal auf deiner lokalen Maschine zu machen. Schritte 2-5 können jedoch immer wieder wiederholt werden, wenn etwas geuptdated wird.

2. Die neuesten Änderungen vom upstream fetchen

git fetch upstream

3. Zum Zielbranch wechseln

Branch-Name ist ausschlaggebend

Beachte, dass wir bei den Übungen auf verschiedene Branches zurückgreifen (jeweils mit git switch <branch-name>) angegeben.

Das heisst die folgenden Instruktionen müssen darauf angepasst werden.

Als fiktives Beispiel:

In der Anleitung ist ein-toller-branchname angegeben. So wird das bei uns zu:

git fetch upstream
git switch ein-toller-branchname
git merge upstream/ein-toller-branchname

Konkretes Beispiel für den Branch 30-website (was wir für die nächste Übung brauchen):

git fetch upstream
git switch '30-website'
git merge 'upstream/30-website'

Falls du schon eigene Änderungen drin hast, gibt es unter Umständen sogenannte merge Konflikte.

Siehe weiter unten, wie man mit diesen umgehen kann. (Und committe deine Änderungen vorher).

Was ist ein Branch in Git?

Ein Branch in Git stellt im Wesentlichen einen unabhängigen Entwicklungspfad dar. Stell dir vor, ein Projekt sei ein Baum. Der Stamm dieses Baumes ist der Hauptentwicklungspfad, oft als main oder master Branch bezeichnet. Wenn du eine neue Funktion entwickeln, einen Bug beheben oder ein Experiment durchführen möchtest, ohne den Hauptentwicklungspfad zu beeinflussen, kannst du einen neuen Zweig (oder Branch) von diesem Stamm erstellen.

Warum sind Branches nützlich?

  1. Isolierung der Arbeit: Branches ermöglichen es dir, an einer neuen Funktion oder einem Bugfix zu arbeiten, ohne den Hauptcode zu beeinflussen. So kann die Hauptversion deines Projekts stabil bleiben, während du gleichzeitig neue Ideen ausprobierst.

  2. Parallelisierung der Arbeit: In Teams ermöglichen Branches mehreren Entwicklern, parallel an unterschiedlichen Funktionen oder Aufgaben zu arbeiten.

  3. Integration und Review: Nachdem die Arbeit in einem Branch abgeschlossen ist, kann dieser Branch in den Hauptbranch (oder einen anderen Zielbranch) über einen Vorgang namens “Merging” integriert werden. Viele Plattformen, wie z.B. GitLab oder GitHub, bieten Funktionen wie “Merge Requests” oder “Pull Requests”, die es erleichtern, Änderungen zu überprüfen, bevor sie in den Zielbranch eingefügt werden.

Grundlegende Branch-Befehle in Git

  • Branch erstellen:

    git switch -c NAME_DES_NEUEN_BRANCHES

  • Zu einem Branch wechseln:

    git switch NAME_DES_BRANCHES

  • Branch löschen::

    git branch -d NAME_DES_BRANCHES

Nehmen wir an, dein Zielbranch heißt main (falls anders, bitte anpassen, z.B. 30-website statt main):

git checkout main

4. Änderungen aus dem upstream in deinen Zielbranch mergen

git merge upstream/main

5. Änderungen in dein eigenes Remote-Repository pushen

Da dein Repository unter deinem Benutzernamen liegt, nehmen wir an, dass es bereits als origin hinzugefügt wurde. Um die Änderungen in dein geforktes Repository auf GitLab zu pushen:

git push origin main
# Hinweis: Ersetze <username> durch deinen tatsächlichen GitLab-Benutzernamen.

Merge Konflikte

Merge-Konflikte treten in Git auf, wenn zwei (oder mehr) Änderungen im selben Bereich eines oder mehrerer Dateien vorgenommen werden und Git nicht automatisch entscheiden kann, welche Version beibehalten werden soll. Das Lösen dieser Konflikte erfordert oft menschliches Eingreifen. Hier sind Schritte und Hinweise, wie du mit einem Merge-Konflikt in Git vorgehen kannst:

Merge-Konflikt erkennen

Wenn ein Merge-Konflikt auftritt, wirst du eine Meldung wie die folgende sehen:

Auto-merging DATEINAME
CONFLICT (content): Merge conflict in DATEINAME
Automatic merge failed; fix conflicts and then commit the result.

Konfliktbereiche in der Datei identifizieren

Öffne die Datei mit dem Konflikt in einem Editor deiner Wahl. Du wirst spezielle Markierungen sehen, die den Konflikt kennzeichnen:

<<<<<<< HEAD
Deine Änderungen
=======
Änderungen aus dem Branch, den du mergen möchtest
>>>>>>> NAME_DES_BRANCHES

Konflikt manuell lösen

  1. Entscheiden, welche Änderungen beibehalten werden sollen: Basierend auf deinem Verständnis des Codes und des Kontexts entscheide, welche Version (oder eine Kombination aus beiden) du beibehalten möchtest.

  2. Bearbeite die Datei: Entferne die Konfliktmarkierungen (<<<<<<<, =======, >>>>>>>) und lass den Code in dem gewünschten Zustand.

Nach der Konfliktlösung

  1. Füge die Datei hinzu: Nachdem du den Konflikt manuell gelöst hast, füge die Datei zum Staging-Bereich hinzu:
git add DATEINAME
  1. Commit: Committe deine Änderungen:
git commit

Hinweis: Bei diesem Commit wird oft eine voreingestellte Commit-Nachricht angezeigt, die den Merge und die betroffenen Dateien anzeigt. Du kannst diese Nachricht beibehalten oder nach Bedarf ändern.

  1. Fortsetzen: Wenn du einen Rebase anstelle eines Merges durchgeführt hast und auf Konflikte gestoßen bist, kannst du den Rebase nach der Konfliktlösung mit git rebase –continue fortsetzen.

Hilfreiche Tipps

  • Verwende spezielle Tools: Es gibt spezialisierte Merge-Tools (z.B. meld, kdiff3, Beyond Compare), die dir helfen können, Konflikte visuell darzustellen und zu lösen.

  • Verstehe den Konflikt: Es ist wichtig, nicht nur den Konflikt zu lösen, sondern auch zu verstehen, warum er aufgetreten ist. Dies hilft dabei, zukünftige Konflikte zu vermeiden und sicherzustellen, dass die Lösung korrekt ist.

  • Kommunikation: Wenn du in einem Team arbeitest und der Konflikt durch Änderungen eines anderen Teammitglieds verursacht wurde, sprich mit dieser Person. Gemeinsames Verständnis und Kollaboration sind oft der Schlüssel zur Lösung komplexer Merge-Konflikte.

Indem du diese Schritte und Tipps befolgst, solltest du in der Lage sein, Merge-Konflikte effektiv zu lösen und sicherzustellen, dass dein Code konsistent und fehlerfrei bleibt.

Zurück nach oben