Git-Übungsaufgaben

git Übungsaufgaben

https://bildung.social/@oerinformatik/110326723919640390

https://oer-informatik.de/git_uebungsaugaben_

tl/dr; (ca. 10 min Lesezeit): Natürlich lernt man git am besten, in dem man es täglich nutzt. Wer aber die git-Integration in der IDE nutzt hat vielleicht keinen Bezug mehr zu den eigentlichen Konsolen-Befehlen des Versionscontrollsystems. Hier daher ein paar Fragen zu git, wie ich sie auch gerne in Klassenarbeiten stelle… (Zuletzt geändert am 27.05.2023)

Leitfragen zum Versionscontrollsystem git

  • Erläutere mithilfe einer Skizze den Unterschied zwischen den Befehlen merge und rebase im Versionskontrollsystem git.

Die Befehle merge und rebase führen beide unterschiedliche Entwicklungszweige (Branches) zusammen.

Bei einem Merge bleiben beide Branches erhalten und es entsteht ein neuer Commit, der die Änderungen zusammenführt:

Bei einem Rebase dagegen werden alle Änderungen des einen Branches an den anderen angehängt. Im ursprünglichen Branch werden diese Änderungen versteckt. Es entsteht somit ein linearer git-Graph ohne Verzweigungen. Im folgenden Bild sind die vorigen Commits zur Verdeutlichung noch angezeigt (hidden C, hidden B), eigentlich sind sie nur noch im linearen Branch vorhanden(B', C').

Linearer Branch eines Rebases
Linearer Branch eines Rebases

Infos dazu können hier (link) nachgelesen werden.
  • Welche Vorteile bietet rebase gegenüber merge?

Durch die lineare Struktur des git-Graphs erscheint das Projekt übersichtlicher. Im Log kann leichter nachvollzogen werden, welche Änderungen wann dazu gekommen sind, da es keine Verzweigungen gibt.
  • Welche potenziellen Probleme können beim Rebasen auftreten, wenn auf ältere Versionen zurückgesprungen werden muss?

Beim Rebase entstehen “virtuelle Commits”, die es so nie in einer Entwicklungsumgebung gegeben hat, für die ggf. auch nie Tests gelaufen sind. Die Version B' im Graph unten hat es so nie gegeben, sie ist erst durch den Rebase entstanden.

Linearer Branch eines Rebases
Linearer Branch eines Rebases

Faktisch wird dies selten zu Problemen führen, sollte aber im Auge behalten werden, wenn größere Projekte mit längeren Graphs per Rebase organisiert werden.

Werden die Änderungen eines main-Branches an einen feature-Branch per rebase verschoben entstehen Probleme, wenn andere Entwickler*innen noch am vormals jüngsten main-Commit gearbeitet hatten - den gibt es dann ja nicht mehr.
  • git nutzt zur Identifizierung einzelner Versionen SHA1-Hashes, wohingegen andere VCS laufende Nummern (1, 2, 3) oder Revisionsnummern (1.1, 1.2 usw.) verwenden. Welche Vorteile und welche Nachteile ergeben sich aus der Identifizierung mit Hashes?

Hashes haben den Vorteil, dass keine zentrale Instanz benötigt wird, die die Reihenfolge der Zählung organisiert. Auf diesem Weg ist ein dezentrales VCS wie git überhaupt erst möglich.

Hashes sind andererseits sehr unhandlich. Daher ermöglicht git, dass man mit abgekürzten Hashes arbeiten kann, um Commits zu identifizieren.
  • git wird als dezentrales Versionskontrollsystem bezeichnet. Erläutere die Eigenschaft der Dezentralität von git in Abgrenzung zu Versionskontrollsystemen mit zentralem Ansatz.

Auch wenn häufig mit pseudo-zentralen Repositories bei Anbietern wie gitlab, github, bitbucket usw. gearbeitet wird, ist jedes Repository eines git-Projekts gleichberechtigt und enthält alle Versionen der anderen Repository-Instanzen seit dem Stand der letzten Synchronisierung (pull/push). Somit kann von jedem lokalen Repository aus das Gesamtprojekt wieder hergestellt werden.

Zentrale Versionskontrollsysteme haben einen “single point of truth” (das zentrale Repository), der auch ein “single point of failure” werden kann, da nicht alle lokalen Clients über alle Informationen verfügen.
  • Definiere, was im VCS git ein Repository ist.

Als Repository wird in _git die Gesamtheit aller bisherigen Änderungen bezeichnet. Alle Versionsstände sind im Repository gespeichert. Im Dateisystem befinden sich diese Daten im .git-Unterordner. Wenn man eine neue Version in das Repostory übernimmt, spricht man von einem Commit.
  • Definiere, was im VCS git ein Commit ist.

Ein Commit ist ein Versionsstand, den man in ein git-Repository zur Versionierung übergibt. Commits werden über Hashwerte eindeutig identifiziert und im git-Graph in ihrer Reihenfolge mit (ggf. mehreren) Vorgängern und Nachfolgern abgebildet.
  • Definiere, was im VCS git ein Branch ist.

Ein Branch ist ein Zeiger auf einen Commit. In der Regel zeigt ein Branch auf das Ende einer Verzweigung, so dass der Begriff häufig synonym mit “Verzweigung” gebraucht wird. Branches und Verzweigungen dienen dazu, den Workflow zu organisieren und parallel an unterschiedlichen Teilaufgaben zu arbeiten, ohne sich bereits in der Entwicklung mit Seiteneffekten der anderen Teilaufgaben beschäftigen zu müssen.
  • In einem Satz: welche Aufgaben haben die git-Befehle add, commit, branch, checkout, rebase, merge, pull, fetch, push, clone

git add : meldet Änderungen für den nächsten commit an - hebt die Dateien vom Workspace auf die Stage

git commit : Fügt einen neuen Versionsstand in das lokale Repository ein.

git branch : Erstellt oder bearbeitet einen neuen Zeiger auf einen Commit, der für Verzweigungen genutzt wird.

git checkout : Ändert den Inhalt des Workspaces auf einen anderen Versionsstand des Repositories.

git rebase : Fügt unterschiedliche Branches zusammen, in dem es die Änderungen des einen an den anderen anhängt (lineare Struktur).

git merge : Fügt unterschiedliche Branches zusammen, in dem es einen neuen Commit erstellt, in dem die Änderungen beider Branches enthalten sind.

git fetch : Holt die aktuellen Versionsstände eines Remote-Repositorys.

git pull : Holt die Änderungen (fetch) und führt sie direkt mit dem lokalen Anpassungen zusammen (merge, rebase).

git push : Überträgt die lokalen Änderungen in das Remote-Repository.

git clone : Erstellt ein lokales Repository auf Basis eines Remote-Repository.
  • Commits werden in git mit einer Nachricht/Beschreibung versehen. Nenne einfache Konventionen, wie diese Nachricht häufig aufgebaut ist sowie ein Beispiel für eine solche Nachricht.

Es gibt eine Vielzahl von Konventionen, wie Commit-Nachrichten aufgebaut sein sollen. Häufig wird in der ersten Zeile der folgende Aufbau genutzt:

TYPE[(SCOPE)]: SUBJECT

Wobei TYPE beschreibt, um welche Art Anpassung es sich handelt (z.B. fix, refactor oder feature), [Scope] das betroffene Modul benennt, an dem es zu Änderungen gekommen ist SUBJECT die Änderung selbst beschreibt, häufig im Präsens gehalten, da es sich im git-Graph dann besser liest.

Im Idealfall folgt danach ein [BODY] und ein [FOOTER], die die Änderungen etwas genauter beschreiben.

Git Szenario 1

Du befindest dich in der Konsole im Ordner meinProjekt, in dem lediglich eine Datei liegt (ReadMe.md).

Ein Verzeichnis im Windows-Explorer mit der Datei Readme.md
Ein Verzeichnis im Windows-Explorer mit der Datei Readme.md
  1. Nenne die vollständigen git-Befehle, mit denen Du ein neues git-Repository erzeugen und die Datei ReadMe.md dem Hauptzweig des Repositorys (also main) mit der Nachricht “initial commit” hinzufügst!
  1. Readme.md wurde im Editor geändert. Nenne die vollständigen Befehle, um die Änderung mit dem Betreff “add description” ins Repository einzufügen (wir bleiben im main-Branch).
  1. Eine neue Datei, index.html wurde erstellt. Nenne die vollständigen Befehle, um die Datei in einem Branch feature/website mit dem Betreff “feat add landing page” ins Repository einzufügen.
  1. Wir befinden uns im main-Branch (siehe git-Graph in Aufgabe e). Es sollen die beiden Branches (main, feature/website) gemerged werden. Der neue Commit soll im main-Branch liegen und der Head darauf zeigen. Die Nachricht soll “merge feature website” lauten. Nenne die vollständigen dafür nötigen git-Befehle!

Variante 1:

Variante 2 Von der anderen Seite sind mehrere Befehle notwendig:

Damit ist zwar die Struktur richtig, aber HEAD zeigt noch auf den falschen Branch:

Wir müssen das also noch ändern:

Jetzt sollte alles passen:
  1. Vervollständige den git-Graph so, wie er nach dem Mergen (Aufgabe d) aussieht. Nenne zur Identifizierung die Commit-Nachricht (kann abgekürzt sein). Streiche Commits durch, die nicht mehr existieren. Trage für alle Branches sowie für Head ein, wo diese sich aktuell befinden (streiche ggf. vorhandene Einträge). Der neuste Commit ist oben. Hashes müssen nicht genannt werden, nur Commit-Nachrichten.
Git-graph, 3 commits im main, nach dem zweiten ein feature-Branch mit einem commit, HEAD auf main
Git-graph, 3 commits im main, nach dem zweiten ein feature-Branch mit einem commit, HEAD auf main
Gleicher Graph wie oben, nur neuer merge-Commit, HEAD zeigt auf main
Gleicher Graph wie oben, nur neuer merge-Commit, HEAD zeigt auf main
  1. Merge-Konflikt: Es erscheint beim Versuch zu mergen eine Fehlermeldung wegen konkurrierenden Änderungen. Welche Schritte sind erforderlich? (Exakte Befehle sind nicht erforderlich, nenne einfach, was zu tun ist.)
  1. Der Konflikt muss behoben werden, bevor weitergearbeitet werden kann.
  2. Die Dateien, bei denen es zu Konflikten kam, müssen per git add hinzugefügt werden
  3. Es muss per git commit der merge-commit erzeugt werden.
  1. Wir befinden uns wieder im main-Branch an der Stelle vor Aufgabe d (siehe git-Graph in Aufgabe h), gehen also eine zweite Variante mit der gleichen Ausgangssituation durch. Diesmal sollen die beiden Branches (main, feature/website) gerebased werden. Der neue Commit soll im main-Branch liegen und der HEAD darauf zeigen. Die Nachricht soll “integrate feature website” lauten. Nenne die vollständigen dafür nötigen git-Befehle!
  1. Vervollständige den git-Graph so, wie er nach dem Rebase (Aufgabe g) aussieht. Nenne zur Identifizierung die Commit-Nachricht (kann abgekürzt sein). Streiche Commits durch, die nicht mehr existieren. Trage für alle Branches sowie für HEAD ein, wo diese sich aktuell befinden (streiche ggf. vorhandene Einträge). Der neuste Commit ist oben. Hashes müssen nicht genannt werden, nur Commit-Nachrichten.
Git-graph, 3 commits im main, nach dem zweiten ein feature-Branch mit einem commit, HEAD auf main
Git-graph, 3 commits im main, nach dem zweiten ein feature-Branch mit einem commit, HEAD auf main
Git-graph wie oben, allerdings gibt es oberhalb der 3 Commits im main-Branch zwei weitere neue (per rebase)
Git-graph wie oben, allerdings gibt es oberhalb der 3 Commits im main-Branch zwei weitere neue (per rebase)

git Beispielszenario 2

Gegeben ist ein Repository mit einem initialen Commit und einem zweiten, mit dem Code veröffentlicht wurde (Branch main).

  • Es soll ein neuer Branch killerFeature erstellt werden,
  • dieser soll ausgecheckt werden,
  • per touch datei.txt simulieren wir Veränderungen an der Codebasis von killerFeature,
  • diese Veränderungen sollen in das Repository übernommen werden,
  • der Branch main soll in den Workspace geladen werden,
  • es wird eine Datei per echo “Hallo Welt”>>beispiel.txt erzeugt,
  • diese Datei wird dem main-Branch hinzugefügt,
  • killerFeature wird in den Workspace geladen und auf den main rebased

Nenne die dazu nötigen vollständigen git-Befehle in der Reihenfolge, in der sie ausgeführt werden müssen.

git Beispielszenario 3

Gegeben ist ein remote Repository mit einem initialen Commit und einem zweiten, mit dem Code veröffentlicht wurde (befindet sich auf dem entfernten Repository im Branch main).

  • Klone das remote-Repository!
  • Nach dem Klonen wird im ursprünglichen remote-Repository ein Commit (durch einen anderen Entwickler*in) durchgeführt.
  • Auch unsere Codebasis ändert sich (z.B. vereinfacht per echo “Hallo Welt”>>beispiel.txt)
  • Die neue Datei wird dem lokalen main-Branch hinzugefügt
  • Die Änderungen sollen in zwei unterschiedlichen Varianten zusammengefügt werden:
  1. per merge
  2. per rebase

Die geänderten Daten sollen auf das remote-Repository übertragen werden.

Nenne die dazu nötigen vollständigen git-Befehle in der Reihenfolge, in der sie ausgeführt werden müssen. Nenne auch für die Varianten a) und b) jeweils den an dieser Stelle nötigen Befehl.

Teile dieses Tutorials

Weitere Übungsaufgaben zur Versionsverwaltung git

  • Zentrale Seite für Übungen zum Branching: Learn git branching: animiertes Tutorial v.a. gut, um die Navigation im git-Tree zu verstehen.

    Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “git Übungsaufgaben” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/git_uebungsaugaben_ veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/devoptools/git. Stand: 27.05.2023.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]

Kommentare gerne per Mastodon, Verbesserungsvorschläge per gitlab issue (siehe oben). Beitrag teilen:

Tags:

You may also like...