02 Quiz: Feature Branch Entwicklung

Richtig: C) Beim Bearbeiten einer Datei landet sie im Zustand “Working Directory” (Modified). Git sieht die Änderung über git status, sie ist aber noch nicht für einen Commit vorgemerkt. Der Fluss ist Working Directory → Staging Area → Repository, mit git add und git commit als Übergängen.

Richtig: A) Die Staging Area gibt Ihnen Kontrolle darüber, was in jeden Commit kommt. Selbst bei mehreren unabhängigen Änderungen in einer Datei können Sie diese mit git add -p separat stagen und committen. Das Ergebnis: eine sauberere History aus fokussierten, logischen Commits — leichter zu reviewen und zu reverten.

Richtig: B) Feature-Branches geben Ihnen eine parallele Zeitlinie zum Experimentieren, Brechen und Iterieren — ohne den stabilen main-Branch zu beeinflussen. Sobald die Arbeit fertig und getestet ist, mergen Sie zurück. main bleibt jederzeit deploybar — die Grundlage professioneller Entwicklung.

Richtig: A) git push -u origin feature lädt den Branch und seine Commits hoch und erstellt den Remote-Tracking-Zeiger origin/feature. Der main-Branch wird überhaupt nicht beeinflusst — sowohl main als auch origin/main bleiben, wo sie waren. Mergen in main erfordert einen expliziten Pull Request.

Richtig: C) Kleine, fokussierte Commits mit klaren Nachrichten sind professionelle Best Practice. Jeder Commit sollte eine logische Arbeitseinheit sein — leicht zu reviewen, verstehen und reverten. Ein riesiger Commit verschleiert die Absicht; ein Commit pro Zeile ist Rauschen. Ziel ist die Mitte: ein Commit pro logischer Änderung.

Richtig: A) Trotz des Namens ist ein Pull Request eigentlich ein Merge Request — Sie bitten darum, dass Ihre Änderungen reviewt und in einen anderen Branch (meist main) gemerged werden. Er schafft Raum für Diskussion, Review, automatisierte Checks und Quality Gates, bevor Code in die Produktion kommt.

Richtig: C) Nach dem Merge ist der Feature-Branch redundant — seine Commits leben in der History von main weiter. Branches sind leichtgewichtige Zeiger, keine Code-Container; sie zu löschen verliert nichts. Alte Branches behalten erzeugt nur Unordnung und Verwirrung.

Richtig: D) Das ist normal: Sie haben git add ausgeführt und dann weiter editiert. Die gestagete Version enthält die früheren Änderungen (bereit für den Commit); die ungestageten Änderungen sind die neuen Edits seit dem letzten git add. Ein git commit jetzt würde nur die gestagete Version aufnehmen. Erneut git add ausführen fügt die neuen Edits hinzu.

Richtig: B) Branch Protection blockiert absichtlich direkte Pushes zu geschützten Branches. Sie müssen einen Feature-Branch erstellen, ihn pushen, einen PR öffnen, erforderliche Checks bestehen und Genehmigung erhalten, bevor Code in main landet. Force-Pushen funktioniert auch nicht — das ist der Sinn. Es ist ein Feature, kein Bug.

Richtig: D) Riesige PRs (über 2000 Zeilen) werden meist durchgewunken statt sorgfältig reviewt. Teilen Sie sie in kleinere, logische PRs von ca. 50–300 Zeilen: bessere Reviews, schnellere Merges, einfacher zu testen, einfacher zu bisecten, wenn etwas kaputt geht.

Richtig: C) Eine gute Commit-Message ist spezifisch und prägnant. Option C nennt den Standard (PEP8) und die Änderung. A ist zu vage, B ist Wegwerf-WIP, D ist ausführlich ohne Spezifika. Das zukünftige Ich wird sich in sechs Monaten beim Bisecten dafür bedanken.

Richtig: D) Starten Sie immer von einem aktuellen main. git pull origin main bringt Ihren lokalen main auf den Stand von origin/main; erst dann den Feature-Branch erstellen. Vom veralteten main zu branchen lädt vermeidbare Merge-Konflikte ein.

Richtig: B) Code-Review ist Zusammenarbeit. Wenn Feedback die Qualität verbessert (und Type Hints tun das), nehmen Sie es an: Committen und pushen Sie zum gleichen Branch — der PR aktualisiert sich automatisch. Ziel ist besserer Code, nicht Workflow-Reinheit.

Richtig: A) Pull Requests sind an Branches gebunden, nicht an Commit-IDs. Neue Commits, die Sie in den Feature-Branch pushen, erscheinen automatisch im PR; Reviewer sehen den neuen Diff, CI-Checks laufen erneut. Deshalb funktioniert iteratives Review reibungslos.

Richtig: D) Das Kernprinzip lautet: main sollte immer stabil und deploybar sein. Feature-Branches isolieren experimentelle und in Arbeit befindliche Arbeit. Pull Requests mit Reviews und Checks sind das Quality Gate, bevor irgendetwas main erreicht.

Richtig: B) Das ist klassische Divergenz: Beide Branches teilen den gemeinsamen Vorfahren B, aber main ist auf M2 weitergezogen, während feature eigene Commits C1, C2, C3 hat. Fast-Forward funktioniert nur, wenn ein Branch direkter Vorfahre des anderen ist.

Um sauber zu integrieren, gibt es zwei Hauptoptionen:

• Merge-Commit: git merge feature auf main erzeugt einen neuen Commit, der beide Historien zusammenführt (explizit, zeigt parallele Arbeit).
• Rebase + Fast-Forward: git rebase main auf feature legt C1, C2, C3 neu auf M2 ab — danach ist ein Fast-Forward möglich (linearere History).

In beiden Fällen geht nichts verloren.