Home

02 Quiz: Feature Branch Entwicklung

October 2025 (2756 Words, 16 Minutes)

exercises quiz chapter-02 git feature-branches pull-requests workflow

Kapitel 02 Quiz: Feature Branch Entwicklung

Anleitung

Dieses Quiz testet Ihr Verständnis der Kernkonzepte aus Kapitel 02 (Feature-Branch-Entwicklung)
Jede Frage hat 4 Optionen mit genau einer richtigen Antwort
Versuchen Sie zu antworten, ohne auf die Vorlesungsmaterialien zurückzugreifen
Konzentrieren Sie sich auf das Verständnis von Konzepten, nicht auf das Auswendiglernen von Details

Frage 1: Gits drei Zustände

Sie haben gerade main.py bearbeitet, um einige PEP8-Verstöße zu beheben. In welchem Zustand befindet sich diese Datei, bevor Sie git add ausführen?

A) Repository (Committed) - die Änderungen sind dauerhaft in Gits History gespeichert
B) Staging Area (Staged) - die Änderungen sind für den nächsten Commit markiert
C) Working Directory (Modified) - die Datei ist geändert, aber Git wurde noch nicht darüber informiert
D) Remote (Pushed) - die Änderungen sind auf GitHub und warten darauf, gepullt zu werden

Antwort anzeigen

Richtige Antwort: C

Wenn Sie eine Datei bearbeiten, gelangt sie in den “Working Directory”-Zustand (auch “Modified”-Zustand genannt). Git weiß, dass sich die Datei geändert hat (Sie können dies mit git status sehen), aber diese Änderungen wurden noch nicht für den Commit vorgemerkt. Sie müssen git add ausführen, um Änderungen in die Staging Area zu verschieben, dann git commit, um sie dauerhaft im Repository zu speichern. Das Drei-Zustände-Modell ist grundlegend: Working Directory → Staging Area → Repository.

Frage 2: Der Zweck der Staging Area

Ihr Teamkollege fragt, warum Git eine Staging Area hat, anstatt Änderungen direkt vom Working Directory zu committen. Was ist die BESTE Erklärung?

A) Die Staging Area ist ein Legacy-Feature aus älteren Versionskontrollsystemen und ist nicht wirklich notwendig
B) Sie ermöglicht es Ihnen, selektiv auszuwählen, welche Änderungen in jeden Commit aufgenommen werden, was logische, fokussierte Commits ermöglicht
C) Sie ist nur für große Teams nützlich; einzelne Entwickler brauchen die Staging Area nicht
D) Die Staging Area führt automatisch Tests vor dem Committen aus, um kaputten Code zu verhindern

Antwort anzeigen

Richtige Antwort: B

Die Staging Area gibt Ihnen Kontrolle darüber, was in jeden Commit aufgenommen wird. Selbst wenn Sie mehrere Änderungen an einer Datei vorgenommen haben (wie Import-Korrekturen, Spacing und Benennung), können Sie diese separat stagen und committen, indem Sie git add -p verwenden. Dies erstellt eine sauberere History mit logischen, fokussierten Commits anstelle eines riesigen “alles behoben”-Commits. Dies erleichtert Code-Reviews, ermöglicht selektive Reverts und hilft Mitarbeitern, Ihre Änderungen zu verstehen. Die Staging Area ist ein mächtiges Feature, das Git von einfacheren Versionskontrollsystemen unterscheidet.

Frage 3: Branch-Grundlagen

Was ist der HAUPTZWECK der Erstellung eines Feature-Branches anstelle der direkten Arbeit am main-Branch?

A) Feature-Branches laufen schneller, weil sie weniger Commits verfolgen müssen
B) Isolation - Ihre experimentelle Arbeit beeinflusst den stabilen Produktionscode nicht, bis sie fertig ist
C) GitHub erfordert Feature-Branches für alle Projekte mit über 100 Commits
D) Feature-Branches führen automatisch Qualitätsprüfungen durch, die Main-Branches überspringen

Antwort anzeigen

Richtige Antwort: B

Der Hauptzweck von Feature-Branches ist Isolation. Wenn Sie einen Branch von main erstellen, erstellen Sie eine parallele Zeitlinie, in der Sie experimentieren, Fehler machen und iterieren können, ohne den stabilen main-Branch zu beeinflussen. Wenn Ihr Feature etwas kaputt macht, können andere Teammitglieder weiterhin am stabilen main-Branch arbeiten. Sobald Ihr Feature vollständig und getestet ist, mergen Sie es zurück. Dies ist die Grundlage der professionellen Softwareentwicklung - Produktionscode stabil halten und gleichzeitig Innovation ermöglichen. Main sollte immer deploybar sein.

Frage 4: Git-Workflow-Verständnis

Sie befinden sich auf einem Feature-Branch und haben mehrere Commits gemacht. Was passiert, wenn Sie zum ersten Mal git push auf diesem Branch ausführen?

A) Git erstellt automatisch einen Pull Request auf GitHub für Sie
B) Der Branch und seine Commits werden auf GitHub hochgeladen, aber main bleibt unverändert
C) Ihre Commits werden direkt in main auf GitHub gemerged
D) Git blockiert den Push und verlangt, dass Sie zuerst einen Pull Request erstellen

Antwort anzeigen

Richtige Antwort: B

Wenn Sie zum ersten Mal einen Feature-Branch pushen (mit git push -u origin feature-name), laden Sie Ihren lokalen Branch und seine Commits auf GitHub hoch. Dies erstellt eine Remote-Kopie Ihres Branches, beeinflusst aber main überhaupt nicht. Die Branches bleiben getrennt. Um Ihre Änderungen in main zu mergen, müssen Sie einen Pull Request erstellen (was eine separate, explizite Aktion ist). Diese Trennung ist beabsichtigt - sie ermöglicht Review und Testing, bevor Änderungen den Produktionscode erreichen.

Frage 5: Commit-Best-Practices

Sie haben mehrere PEP8-Verstöße in einer Datei behoben: Import-Probleme, Spacing-Probleme und Namenskonventionen. Was ist die BESTE Commit-Strategie?

A) Einen großen Commit mit der Nachricht “Alle PEP8-Verstöße behoben” machen, um die History einfach zu halten
B) Separate fokussierte Commits für jeden Fix-Typ (Imports, Spacing, Benennung) mit beschreibenden Nachrichten machen
C) Nicht committen, bis alle Verstöße behoben sind, um die Git-History nicht zu überladen
D) Nach jeder einzelnen Zeilenänderung committen, um maximale Granularität zu haben

Antwort anzeigen

Richtige Antwort: B

Kleine, fokussierte Commits mit klaren Nachrichten sind eine professionelle Best Practice. Durch die Trennung verschiedener Arten von Korrekturen in verschiedene Commits (“Fix PEP8: Separate imports”, “Fix PEP8: Add spacing around operators”, “Fix PEP8: Rename to snake_case”) erstellen Sie eine logische Progression, die einfacher zu überprüfen, zu verstehen und bei Bedarf rückgängig zu machen ist. Ein riesiger Commit macht es schwer zu verstehen, was sich geändert hat und warum. Zu viele winzige Commits erzeugen Rauschen. Das Ziel sind logische Arbeitseinheiten - jeder Commit sollte einen klaren, einzelnen Zweck haben.

Frage 6: Pull-Request-Grundlagen

Was ist der HAUPTZWECK eines Pull Requests (PR)?

A) Ihre Änderungen automatisch ohne manuelle Intervention in main zu mergen
B) Die neuesten Änderungen von main in Ihren Feature-Branch zu pullen
C) Anzufordern, dass Ihre Änderungen überprüft und in den Ziel-Branch gemerged werden
D) Ihre lokalen Commits in das Remote-Repository auf GitHub zu pushen

Antwort anzeigen

Richtige Antwort: C

Trotz des verwirrenden Namens ist ein Pull Request tatsächlich ein Merge-Request - Sie bitten darum, dass Ihre Änderungen überprüft und in einen anderen Branch (normalerweise main) gemerged werden. Ein PR schafft einen Raum für Diskussion, Code-Review, automatisierte Checks und Zusammenarbeit, bevor Code die Produktion erreicht. Es ist nicht automatisch (das würde den Zweck zunichte machen), es geht nicht ums Pullen von main (das ist git pull) und es geht nicht ums Pushen von Commits (das ist git push). PRs sind der Eckpfeiler der kollaborativen Entwicklung und von Quality Gates.

Frage 7: Feature-Branch-Lebenszyklus

Ihr Pull Request wurde gerade genehmigt und in main gemerged. Was sollten Sie mit Ihrem Feature-Branch tun?

A) Ihn für immer als Backup behalten, falls mit main etwas schief geht
B) Ihn weiter für Ihr nächstes Feature verwenden, um zu viele Branches zu vermeiden
C) Sowohl den lokalen als auch den Remote-Feature-Branch löschen - er hat seinen Zweck erfüllt
D) Ihn archivieren, indem Sie ihn in “completed/feature-name” umbenennen zur Dokumentation

Antwort anzeigen

Richtige Antwort: C

Sobald ein Feature-Branch gemerged ist, sollte er sowohl lokal als auch auf GitHub gelöscht werden. Die Arbeit ist jetzt Teil von main, daher ist der Branch redundant. Alte Branches zu behalten erzeugt Unordnung und Verwirrung (“wird daran noch gearbeitet?”). Branches in Git sind leichtgewichtige Zeiger, keine Code-Container - die Commits existieren weiterhin in der History von main, auch nach dem Löschen des Branches. Für Ihr nächstes Feature erstellen Sie einen neuen Branch vom aktualisierten main. Dies hält Ihr Repository sauber und Ihren Workflow klar.

Frage 8: Git-Status-Interpretation

Sie führen git status aus und sehen eine Datei sowohl unter “Changes to be committed” als auch unter “Changes not staged for commit” aufgelistet. Was bedeutet das?

A) Git ist verwirrt und Sie müssen das Repository zurücksetzen
B) Sie haben einige Änderungen gestaged und danach zusätzliche Bearbeitungen an derselben Datei vorgenommen
C) Die Datei hat Konflikte, die vor dem Committen gelöst werden müssen
D) Das ist unmöglich - eine Datei kann nicht gleichzeitig in beiden Zuständen sein

Antwort anzeigen

Richtige Antwort: B

Das ist völlig normal! Es bedeutet, dass Sie git add verwendet haben, um einige Änderungen an der Datei zu stagen, und sie dann weiter bearbeitet haben. Die gestagede Version enthält Ihre früheren Bearbeitungen (bereit für Commit), während die nicht gestageden Änderungen Ihre neuen Bearbeitungen seit dem letzten git add sind. Wenn Sie jetzt committen, werden nur die gestageden Änderungen einbezogen. Sie müssten erneut git add ausführen, um die neueren Änderungen einzubeziehen. Dies zeigt, warum die Staging Area mächtig ist - sie lässt Sie genau festlegen, was in jeden Commit aufgenommen wird.

Frage 9: Branch-Protection-Verständnis

Ihr Team hat Branch Protection auf main aktiviert. Sie versuchen, direkt zu main zu pushen und bekommen einen Fehler. Was passiert?

A) GitHub ist vorübergehend ausgefallen und Sie sollten es später erneut versuchen
B) Branch-Protection-Regeln verhindern direkte Pushes zu main - Sie müssen einen Pull Request verwenden
C) Sie haben keine Schreibberechtigungen für das Repository
D) Sie müssen mit git push --force force-pushen, um den Schutz zu überschreiben

Antwort anzeigen

Richtige Antwort: B

Branch Protection blockiert absichtlich direkte Pushes zu geschützten Branches wie main. Dies erzwingt den professionellen Workflow: Sie müssen einen Feature-Branch erstellen, ihn pushen, einen Pull Request öffnen, erforderliche Checks bestehen und Genehmigung erhalten, bevor Ihr Code main erreicht. Dies verhindert Unfälle (“ups, kaputten Code gepusht”), erzwingt Code-Review und stellt sicher, dass Quality Gates bestanden werden. Force-Pushen funktioniert auch nicht - der Schutz gilt für alle (sogar Admins, wenn richtig konfiguriert). Dies ist ein Feature, kein Bug!

Frage 10: Pull-Request-Größen-Best-Practices

Sie haben an einem großen Feature gearbeitet, das 15 Dateien berührt und über 2000 Zeilen ändert. Was ist der BESTE Ansatz für Ihren Pull Request?

A) Einen großen PR mit allen Änderungen einreichen - es ist ein Feature, also sollte es ein PR sein
B) Ihn in mehrere kleinere PRs aufteilen, wobei jeder sich auf eine logische Teilmenge des Features konzentriert
C) Warten, bis Sie Tests und Dokumentation hinzugefügt haben, bevor Sie einen PR erstellen
D) Den großen PR erstellen, ihn aber als “Draft” markieren, damit Reviewer wissen, dass er groß ist

Antwort anzeigen

Richtige Antwort: B

Große PRs (2000+ Zeilen) sind überwältigend zu reviewen und werden oft “durchgewunken” ohne sorgfältige Prüfung, was zu Bugs führt. Teilen Sie große Features in kleinere, logische PRs auf - vielleicht nach Komponente, Schicht oder inkrementeller Funktionalität. Jeder PR sollte idealerweise 50-300 Zeilen haben, mit einem klaren Zweck. Kleinere PRs bekommen bessere Reviews, werden schneller gemerged, sind einfacher zu testen, und wenn etwas kaputt geht, ist es einfacher zu identifizieren, welcher PR die Ursache war. Ja, dies erfordert mehr Planung, aber diese Planung selbst verbessert die Code-Qualität.

Frage 11: Commit-Message-Qualität

Welche Commit-Message folgt Best Practices für professionelle Entwicklung?

A) “Zeug repariert”
B) “WIP”
C) “Fix PEP8: Separate multiple imports onto different lines”
D) “main.py mit den Änderungen aktualisiert, die wir gestern im Meeting über Code-Qualitätsverbesserungen besprochen haben”

Antwort anzeigen

Richtige Antwort: C

Gute Commit-Messages sind spezifisch und prägnant. Option C folgt dem Muster: “Was: Kurze Beschreibung” und referenziert den Standard (PEP8). Option A ist zu vage (“welches Zeug?”), Option B ist für temporäre Commits, die nicht gepusht werden sollten, und Option D ist zu ausführlich und unspezifisch. Eine gute Commit-Message sollte jemandem ermöglichen zu verstehen, was sich geändert hat und warum, ohne den Diff lesen zu müssen. Das zukünftige Ich (oder Ihre Teamkollegen) wird Ihnen danken, wenn Sie sechs Monate später debuggen oder die History verstehen.

Frage 12: Branch-Workflow-Strategie

Sie beginnen mit der Arbeit an einem neuen Feature. Was ist der richtige erste Schritt?

A) Sofort auf Ihrem aktuellen Branch mit dem Coden beginnen, um Zeit zu sparen
B) Einen Feature-Branch direkt von Ihrem aktuellen Branch erstellen
C) Zu main wechseln, neueste Änderungen pullen, dann einen Feature-Branch vom aktualisierten main erstellen
D) Das Repository forken und in Ihrem Fork arbeiten statt Branches zu verwenden

Antwort anzeigen

Richtige Antwort: C

Starten Sie immer von einem aktualisierten main-Branch. Zuerst git checkout main, dann git pull origin main, um die neuesten Änderungen vom Team zu erhalten. Dann erstellen Sie Ihren Feature-Branch mit git checkout -b feature/your-feature. Dies stellt sicher, dass Ihr Feature auf dem neuesten Produktionscode aufbaut und minimiert Merge-Konflikte später. Von einem veralteten main oder einem anderen Feature-Branch zu starten kann zu Konflikten und kaputtem Code führen. Forks sind für externe Mitwirkende, nicht für Teammitglieder mit Schreibzugriff.

Frage 13: Code-Review-Zweck

Während des Code-Reviews Ihres Pull Requests schlägt ein Teamkollege vor, Type Hints zu Ihren Funktionen hinzuzufügen. Was ist die BESTE Reaktion?

A) Den Vorschlag ablehnen - der Code funktioniert gut ohne Type Hints
B) Das Feedback akzeptieren, Type Hints hinzufügen, committen und pushen, um den PR zu aktualisieren
C) Diesen PR schließen und einen neuen mit Type Hints öffnen, um PRs getrennt zu halten
D) Argumentieren, dass Type Hints in einem separaten PR sein sollten, da sie nicht Teil Ihrer ursprünglichen Änderungen waren

Antwort anzeigen

Richtige Antwort: B

Code-Review geht um Zusammenarbeit und Verbesserung. Wenn Feedback die Code-Qualität verbessert (und Type Hints tun das definitiv), nehmen Sie es an! Machen Sie die Änderungen, committen Sie sie zum selben Branch und pushen Sie - dies aktualisiert den PR automatisch. Sie brauchen keinen neuen PR für Review-angeforderte Änderungen. Während “separate Concerns in separaten PRs” generell guter Rat ist, macht das Hinzufügen von Type Hints zu Funktionen, die Sie bereits anfassen, im selben PR Sinn. Das Ziel ist besserer Code, nicht Argumente über Workflow-Reinheit zu gewinnen.

Frage 14: PR-Updates verstehen

Sie haben einen Pull Request geöffnet. Ihr Teamkollege fordert Änderungen an. Nachdem Sie neue Commits zu Ihrem Feature-Branch gepusht haben, was passiert mit dem PR?

A) Sie müssen den alten PR schließen und einen neuen mit den aktualisierten Commits öffnen
B) Der PR wird automatisch aktualisiert, um Ihre neuen Commits einzubeziehen
C) Sie müssen die neuen Commits manuell über die GitHub-Oberfläche zum PR hinzufügen
D) Der PR ist gesperrt, bis ein Maintainer die neuen Commits genehmigt

Antwort anzeigen

Richtige Antwort: B

Pull Requests sind mit Branches verknüpft, nicht mit Commits. Wenn Sie neue Commits zum selben Feature-Branch pushen, wird der PR automatisch aktualisiert, um sie einzubeziehen. Deshalb ist der PR-Workflow so mächtig - er unterstützt iterative Verbesserung. Sie können auf Feedback reagieren, Commits hinzufügen, und die Konversation geht im selben PR weiter. Die Commit-History wächst, Reviewer können Ihre Änderungen sehen, und automatisierte Checks laufen erneut. Keine Notwendigkeit, neue PRs zu erstellen oder irgendetwas manuell zu aktualisieren.

Frage 15: Git-Workflow-Philosophie

Was ist das grundlegende Prinzip hinter dem Feature-Branch-Workflow?

A) So viele Branches wie möglich erstellen, um Gits Features zu maximieren
B) Main immer stabil und deploybar halten, indem Entwicklungsarbeit isoliert wird
C) Merging vermeiden, um die Chance von Merge-Konflikten zu reduzieren
D) Commits so groß wie möglich machen, um die Anzahl der benötigten Merges zu minimieren

Antwort anzeigen

Richtige Antwort: B

Das Kernprinzip ist: main sollte immer stabil und deploybar sein. Feature-Branches bieten Isolation für experimentelle Arbeit, Bug-Fixes und neue Features. Wenn die Arbeit vollständig und getestet ist, wird sie in main gemerged. Dies bedeutet, dass jeder das Repository klonen, main auschecken und funktionierenden Code haben kann. Wenn jemand kaputten Code direkt zu main pusht, ist jeder blockiert. Feature-Branches mit Pull Requests stellen Quality Gates (Tests, Reviews, Checks) sicher, bevor Code die Produktion erreicht. Dies ist die Grundlage moderner kollaborativer Softwareentwicklung.

Bewertungsleitfaden

13-15 richtig: Ausgezeichnet! Sie haben ein starkes Verständnis von Git-Workflows und kollaborativer Entwicklung
10-12 richtig: Gutes Verständnis! Überprüfen Sie die Bereiche, die Sie verpasst haben, um Ihr Wissen zu festigen
7-9 richtig: Faires Verständnis. Besuchen Sie die Vorlesungsmaterialien erneut, besonders die Abschnitte zu Git-Zuständen und PR-Workflows
Unter 7: Bitte überprüfen Sie die Vorlesung sorgfältig und erwägen Sie das Üben mit einem Beispiel-Repository

Wichtige Erkenntnisse zum Merken

Gits drei Zustände - Working Directory (modified) → Staging Area (staged) → Repository (committed). Diesen Fluss zu verstehen ist fundamental.
Zweck der Staging Area - Gibt Ihnen Kontrolle, um fokussierte, logische Commits zu erstellen, anstatt alles auf einmal zu committen.
Feature-Branch-Isolation - Arbeiten Sie an Features isoliert, damit main stabil und deploybar bleibt. Dies ist die Grundlage professioneller Workflows.
Branch Protection - Verhindert direkte Pushes zu main, erzwingt den Pull-Request-Workflow und stellt Code-Review sicher.
Pull-Request-Workflow - Branch erstellen → Commits machen → Pushen → PR öffnen → Review → Mergen → Branch löschen. Jeder Schritt hat einen Zweck.
Commit-Best-Practices - Kleine, fokussierte Commits mit klaren Messages. Jeder Commit sollte eine logische Arbeitseinheit darstellen.
PR-Größe ist wichtig - Halten Sie Pull Requests klein (50-300 Zeilen) für bessere Reviews. Teilen Sie große Features in mehrere PRs auf.
Main-Branch-Heiligkeit - main sollte immer stabil und deploybar sein. Niemals direkt pushen; immer Feature-Branches und PRs verwenden.
Code-Review ist Zusammenarbeit - Feedback verbessert Code-Qualität. Nehmen Sie Vorschläge an und iterieren Sie an Ihrer Arbeit.
PR-Updates sind automatisch - Pushen Sie neue Commits zu Ihrem Feature-Branch und der PR wird automatisch aktualisiert. Keine Notwendigkeit, neue PRs zu erstellen.