Aufgaben Git
Zehn IHK-Aufgaben durch den gesamten Git-Kurs: Warum VCS, Grundbegriffe, Befehle, Remotes, Branching, Merge/Rebase, Konflikte, Workflows, Pull Requests. Mix aus MC, Mehrfachauswahl, Zuordnung, Reihenfolge und einer offenen Aufgabe. Live-Auswertung oben, am Ende eine Note.
Aufgabe 12 Punkte
Zentrale vs. verteilte Versionsverwaltung
Welche Aussage über verteilte VCS wie Git ist korrekt?
Bei einem verteilten VCS speichert nur ein zentraler Server die Historie.
Jeder Entwickler hat eine vollständige Kopie der Historie lokal, kann offline commiten und branchen.
Verteilte VCS sind langsamer als zentrale, weil Daten dupliziert werden müssen.
Bei Git muss man ständig online sein, um zu commiten.
Richtig. Bei verteilten VCS wie Git hat jeder Entwickler die komplette Historie lokal. Offline-Arbeit (Commits, Branching, Logs) ist möglich – nur push/pull braucht Netz. Im Gegensatz zu zentralen VCS wie SVN, wo der Server der Single Point of Truth ist. Vgl. L1.
Aufgabe 23 Punkte
Git-Grundbegriffe zuordnen
Ordne jeden Git-Begriff seiner korrekten Definition zu. Klick zuerst einen Begriff, dann die passende Definition:
Commit
Branch
HEAD
Remote
Tag
Pointer auf einen Commit, der eine parallele Entwicklungslinie repräsentiert
Snapshot mit SHA-1-Hash, Autor, Datum, Nachricht und Parent-Referenz
Zeiger, der angibt, auf welchem Branch/Commit man gerade arbeitet
Server-Kopie des Repos (z.B. auf GitHub), Standardname „origin"
Fester Name für einen Commit, bewegt sich nicht – ideal für Releases
Auswertung: Commit = Snapshot mit SHA-1. Branch = beweglicher Pointer auf Commit. HEAD = aktueller Stand. Remote = Server-Kopie. Tag = fester Name für Commit. Vgl. L2.
Aufgabe 32 Punkte
Die drei Git-Bereiche
Bring die Bereiche/Befehle in die korrekte Reihenfolge – wie eine Datei von „du tippst gerade Code" bis zum Repository wandert:
Aufgabe 43 Punkte
Grundlegende Befehle
Welche der folgenden Befehle verändern den Inhalt deines Working Directory NICHT? Wähle alle zutreffenden:
✓
git status✓
git log✓
git pull✓
git fetch✓
git diff✓
git restore✓
git merge
Auswertung: Read-only sind
git status, git log, git fetch (nur Remote-Refs!), git diff. Verändern Working Directory: git pull (= fetch + merge!), git restore (wirft Änderungen weg!), git merge. Wichtiger Unterschied: fetch ändert nur origin/*-Refs, pull auch das Working Directory. Vgl. L4.
Aufgabe 52 Punkte
Branch erstellen
Welcher Befehl erstellt einen neuen Branch namens
feature/login und wechselt direkt dorthin?git branch feature/logingit checkout feature/logingit switch -c feature/logingit merge feature/login
Richtig.
git switch -c <name> macht beides: erstellt UND wechselt. Alternativ funktioniert noch git checkout -b <name>. git branch <name> alleine erstellt nur, wechselt nicht. Vgl. L5.
Eselsbrücke: -c = create.
Aufgabe 63 Punkte
Merge vs. Rebase
Welche Aussagen zu
git merge und git rebase sind korrekt? Wähle alle zutreffenden:✓Ein Merge erstellt einen neuen Commit mit zwei Eltern, ein Rebase nicht.
✓Rebase erzeugt eine lineare Historie, Merge eine „zackige".
✓Rebase ist ungefährlicher als Merge.
✓Rebase sollte nie auf bereits gepushten Branches durchgeführt werden, die andere nutzen.
✓Beim Rebase bekommen die umgesetzten Commits neue SHA-Hashes.
✓Merge ist immer besser als Rebase.
Auswertung: Korrekt ist 1, 2, 4, 5. Rebase = lineare Historie, aber Hashes ändern sich → niemals auf geteilten Branches. Merge = ehrliche Historie, aber Merge-Commits können unübersichtlich werden. Goldene Regel: lokale Branches rebasen, geteilte mergen. Vgl. L6.
Aufgabe 73 Punkte
Merge-Konflikt auflösen
In einer Datei stehen die folgenden Zeilen. Was bedeuten sie und wie löst du den Konflikt?
<<<<<<< HEAD const taxRate = 0.19; ======= const taxRate = 0.07; >>>>>>> feature/reduced-vat
Git ist kaputt – die Datei muss neu erstellt werden.
Die HEAD-Variante gewinnt automatisch nach
git commit.Beide Branches haben dieselbe Zeile unterschiedlich geändert. Ich muss manuell entscheiden, Marker entfernen,
git add + git commit ausführen.Den Konflikt mit
git rebase --abort ignorieren und einfach pushen.
Richtig. Die Marker zeigen: HEAD-Branch (aktuelle Version) hat 0.19, feature/reduced-vat hat 0.07. Auflösung: Datei editieren, eine Variante wählen (oder kombinieren), alle Marker entfernen, dann
git add <datei> + git commit. Vgl. L7.
Merker: HEAD = aktueller Branch, alles nach ====== = die andere Variante.
Aufgabe 83 Punkte
Git-Workflows zuordnen
Ordne jede Beschreibung dem richtigen Workflow zu:
GitHub Flow
Gitflow
Trunk-Based
Nur main + kurzlebige Feature-Branches mit PR – Standard für moderne SaaS
Mehrere parallele Branches: main, develop, release/*, hotfix/* – passt zu versionierten Releases
Alle commiten direkt in main, Feature Flags verstecken halbfertige Features – erfordert hohe Test-Disziplin
Beliebt bei Google, Meta und anderen Big-Tech-Firmen mit Continuous Deployment
Heute oft als zu komplex angesehen, in Enterprise und Mobile-Apps mit App-Store-Releases noch sinnvoll
2011 in einem GitHub-Blog-Post als Standard etabliert: simpel, modern, ein Branch pro Feature
Auswertung: GitHub Flow = nur main + Feature-Branches. Gitflow = mehrere Hauptbranches (main/develop/release/hotfix). Trunk-Based = alles direkt in main + Feature Flags. Vgl. L8.
Aufgabe 92 Punkte
Pull Request Workflow
Bring die Schritte eines typischen Feature-Branch-Workflows mit Pull Request in die richtige Reihenfolge:
Korrekte Reihenfolge: main pullen → branch erstellen → arbeiten + commit → push (mit -u) → PR öffnen → Review-Feedback → Approval → Merge → Branch lokal löschen. Vgl. L9.
Aufgabe 105 Punkte
Praxis: Tag im Team-Leben
Beschreibe in 4-7 Sätzen einen typischen Arbeitstag mit Git: Du startest morgens, sollst ein neues Feature umsetzen, am Ende soll der Code im Hauptbranch landen. Welche Schritte gehst du? Welche Befehle nutzt du?
Das System prüft, ob die wichtigsten Stichworte vorkommen:
Das System prüft, ob die wichtigsten Stichworte vorkommen:
Mögliche Musterlösung: Morgens als erstes
git switch main && git pull, um den neuesten Stand zu haben. Dann git switch -c feature/login-button für einen neuen Branch. Code schreiben, regelmäßig git add und git commit -m "..." mit Conventional-Commit-Messages. Dann git push -u origin feature/login-button zum Hochladen. Auf GitHub einen Pull Request öffnen, Reviewer einladen. Nach Review-Feedback Anpassungen einarbeiten, ggf. git rebase main, wenn main weitergegangen ist. Bei Konflikten Marker auflösen, git add, git rebase --continue. Nach Approval Merge via PR, lokal mit git branch -d feature/login-button aufräumen. Vgl. L3-L9.
📊 Auswertung
Punkte
0
Prozent
0%
Note
–
Aufgaben gelöst
0/10
Verwandte Lektionen zum Wiederholen: L2 Grundbegriffe · L4 Remotes · L6 Merge/Rebase · L7 Konflikte · L9 Pull Requests
Nächste Kurse: K55 CI/CD & Automatisierung baut direkt auf Git auf. K53 Toolchain für IDEs und Build-Tools. K52 Testen für CI-Pipeline-Tests.