Git-Interviewfragen: 25 Fragen mit Antworten fürs Vorstellungsgespräch

Git kommt in fast jedem Vorstellungsgespräch für Entwickler, Tester oder DevOps Engineers vor – mal als eigener Block, mal ganz nebenbei („Wie würden Sie ein missglücktes Release zurückrollen?“). Dem Interviewer geht es weniger um auswendig gelernte Flags als um das Verständnis des Modells: Was ist ein Commit, worauf zeigt ein Branch, was schreibt die Historie um? Im Folgenden finden Sie die 25 häufigsten Fragen mit Antworten auf einem Niveau, das einen guten Eindruck hinterlässt.

Die Fragen reichen von den Grundlagen bis zu fortgeschrittenen Themen. Bringen Sie im Gespräch nach Möglichkeit ein kurzes Beispiel aus der Praxis – das zählt mehr als nacherzählte Dokumentation.

Grundlagenfragen

1. Was ist Git, und was unterscheidet ein verteiltes Versionskontrollsystem von einem zentralen?

Git ist ein verteiltes Versionskontrollsystem: Es speichert die Änderungshistorie eines Projekts und erlaubt mehreren Personen, parallel daran zu arbeiten. Bei zentralen Systemen (etwa SVN) liegt die vollständige Historie auf einem Server, der Entwickler hat nur eine Arbeitskopie. In Git enthält jeder Klon die komplette Historie, deshalb funktionieren Commits, Branches, Log und Merges lokal und ohne Netzwerk.

Die praktischen Vorteile: hohe Geschwindigkeit, Offline-Arbeit, kein Single Point of Failure. Ein Server wie GitHub oder GitLab ist in Git lediglich die Teamabsprache über die „Hauptkopie“, keine technische Notwendigkeit.

2. Aus welchen drei Bereichen besteht die Arbeit mit Git?

Arbeitsverzeichnis (Dateien auf der Platte), Index bzw. Staging Area (vorbereiteter Snapshot des nächsten Commits) und lokales Repository (der Ordner .git mit der Historie). git add überträgt Änderungen vom Arbeitsverzeichnis in den Index, git commit vom Index ins Repository.

Ein guter Zusatzpunkt: die vierte Zone erwähnen, das Remote-Repository, sowie die Befehle git push und git fetch, die damit arbeiten.

3. Wozu braucht man den Index, wenn man auch direkt committen könnte?

Mit dem Index stellen Sie einen Commit bewusst zusammen: Von zehn geänderten Dateien committen Sie die drei, die zu einer Aufgabe gehören, und lassen den Rest liegen. Mit git add -p können Sie sogar einzelne Abschnitte innerhalb einer Datei auswählen.

Das ist die Grundlage atomarer Commits: ein Commit – eine logische Änderung. Eine solche Historie lässt sich leicht lesen, reviewen, per revert zurücknehmen und per cherry-pick übertragen.

4. Was ist ein Commit aus Sicht der Git-Interna?

Ein Commit ist ein Objekt mit einem Verweis auf einen Tree – einen Snapshot aller Projektdateien –, Verweisen auf Parent-Commits, Author, Committer, Zeitstempeln und Message. Identifiziert wird er durch einen SHA-1-Hash über den gesamten Inhalt (neuere Versionen unterstützen experimentell SHA-256).

Der Kernpunkt: Git speichert Snapshots, keine Diffs. Unveränderte Dateien werden nicht dupliziert – der Tree verweist einfach auf denselben Blob. Da der Hash vom Parent abhängt, lässt sich ein alter Commit nicht ändern, ohne die Hashes aller folgenden zu ändern.

5. Was ist ein Branch und was ist HEAD?

Ein Branch ist nur ein beweglicher Zeiger auf einen Commit – eine Datei in .git/refs/heads/ mit einem Hash darin. Deshalb ist das Anlegen eines Branches in Git sofort erledigt und kopiert nichts. Bei einem neuen Commit rückt der Zeiger des aktuellen Branches auf diesen vor.

HEAD ist der Zeiger darauf, wo Sie sich gerade befinden; normalerweise zeigt er auf einen Branch (ref: refs/heads/main). Wechseln Sie auf einen bestimmten Commit oder Tag, zeigt HEAD direkt auf den Commit – das ist der Zustand detached HEAD.

6. Was ist detached HEAD und warum ist es riskant?

Das ist der Zustand, in dem HEAD auf einen Commit statt auf einen Branch zeigt, etwa nach git switch --detach v1.0 oder git checkout a1b2c3d. Sie können den Code ansehen und sogar committen, aber neue Commits gehören zu keinem Branch.

Wechseln Sie danach auf einen anderen Branch, werden diese Commits unerreichbar und irgendwann von der Garbage Collection entfernt. Um die Arbeit zu sichern, legen Sie einen Branch an: git switch -c fix-from-detached. Haben Sie schon gewechselt, finden Sie den Hash in git reflog.

7. Was ist der Unterschied zwischen git fetch und git pull?

git fetch lädt neue Commits herunter und aktualisiert Remote-Tracking-Branches wie origin/main, lässt aber Ihre lokalen Branches und Dateien in Ruhe. git pull ist fetch plus Integration: standardmäßig per merge, mit dem Flag --rebase oder der Einstellung pull.rebase=true per Rebase.

Erfahrene Entwickler führen fetch oft separat aus, sehen sich git log HEAD..origin/main an und entscheiden erst dann, wie sie die Änderungen integrieren.

8. Wie funktioniert .gitignore, und warum wird eine Datei trotz Eintrag weiter getrackt?

.gitignore definiert Muster für Dateien, die Git nicht zum Hinzufügen anbieten soll: Abhängigkeiten, Build-Ergebnisse, Logs, lokale Konfigurationen mit Secrets. Die Regeln gelten nur für untracked Dateien.

Wurde eine Datei bereits committet, hat der Ignore-Eintrag keine Wirkung. Sie müssen sie aus dem Index nehmen und auf der Platte behalten: git rm --cached config.local.php – und diese Löschung committen. Welche Regel greift, zeigt git check-ignore -v pfad.

Branches, Merges und Konflikte

9. Was ist ein Fast-Forward-Merge?

Hat sich der Zielbranch seit der Abzweigung nicht weiterentwickelt, verschiebt Git beim Merge einfach dessen Zeiger auf den letzten Commit des einzumergenden Branches – ohne neuen Commit. Die Historie bleibt linear.

Das Flag --no-ff erzwingt auch in diesem Fall einen Merge-Commit: So ist in der Historie zu sehen, dass eine Gruppe von Commits ein eigenes Feature war. Das Flag --ff-only erlaubt umgekehrt nur Fast-Forward und bricht ab, wenn ein echter Merge nötig wäre.

10. Wie entsteht ein Merge-Konflikt und wie lösen Sie ihn?

Ein Konflikt entsteht, wenn in beiden Branches dieselben Zeilen einer Datei geändert wurden (oder die Datei in einem Branch gelöscht und im anderen geändert wurde) und Git nicht automatisch entscheiden kann. Git hält den Merge an und markiert die Stellen mit <<<<<<<, =======, >>>>>>>.

git status                 # Liste der Dateien mit Konflikten
# Dateien bearbeiten, die richtige Variante behalten
git add app.js
git commit                 # beim Merge; beim Rebase – git rebase --continue

Eine gute Antwort umfasst auch Vorbeugung: kleine Branches, häufiges pull aus dem Hauptbranch, Absprachen zur Formatierung. Und git merge --abort, falls Sie zurückrudern müssen.

11. Was unterscheidet merge und rebase?

merge führt zwei Branches über einen Merge-Commit mit zwei Parents zusammen; bestehende Commits bleiben unverändert, die Historie bildet die parallele Arbeit ehrlich ab. rebase setzt die Commits Ihres Branches auf einen anderen Branch um, indem es Kopien mit neuen Hashes erzeugt; die Historie wird linear.

Die übliche Regel: rebase, um den eigenen lokalen Branch vor der Veröffentlichung aufzuräumen, merge für die Integration in gemeinsame Branches. Ein Rebase veröffentlichter Commits, auf denen andere arbeiten, führt zu Duplikaten und Chaos.

12. Was ist ein interaktiver Rebase und wofür braucht man ihn?

git rebase -i HEAD~5 öffnet eine Liste der letzten fünf Commits, in der Sie für jeden eine Aktion wählen: pick – behalten, reword – Message ändern, edit – anhalten und korrigieren, squash und fixup – mit dem vorherigen verschmelzen, drop – entfernen. Die Zeilen lassen sich umsortieren.

Typisches Szenario: vor dem Pull Request aus „wip“, „fix typo“, „noch ein Fix“ zwei, drei sinnvolle Commits machen. Praktische Kombination: git commit --fixup=<hash> und anschließend git rebase -i --autosquash.

13. Was macht ein Squash-Merge und wann wählt man ihn?

Beim Squash-Merge werden alle Commits eines Branches zu einem einzigen Commit im Zielbranch zusammengefasst (git merge --squash oder der entsprechende Button auf GitHub/GitLab). Der Hauptbranch erhält einen Commit pro Feature.

Vorteil: eine saubere main-Historie. Nachteil: Die detaillierte Historie innerhalb des Features geht verloren, und Git betrachtet den Quellbranch nicht als gemergt – git branch -d verweigert daher das Löschen ohne -D.

14. Was ist cherry-pick und wann ist es angebracht?

git cherry-pick <hash> wendet die Änderungen eines einzelnen Commits auf den aktuellen Branch an und erzeugt einen neuen Commit mit gleichem Inhalt, aber anderem Hash. Der Klassiker: einen Bugfix von develop in einen Release- oder Hotfix-Branch übernehmen.

Übertreiben sollte man es nicht: Derselbe Fix lebt in zwei Commits, und beim späteren Merge der Branches drohen Konflikte. Das Flag -x fügt der Message einen Verweis auf den Ursprungscommit hinzu.

Änderungen rückgängig machen und wiederherstellen

15. Was unterscheidet git reset --soft, --mixed und --hard?

Modus	Branch-Zeiger	Index	Arbeitsverzeichnis
--soft	wird verschoben	unverändert	unverändert
--mixed (Standard)	wird verschoben	wird zurückgesetzt	unverändert
--hard	wird verschoben	wird zurückgesetzt	wird zurückgesetzt, Änderungen gehen verloren

git reset --soft HEAD~3 eignet sich, um die letzten drei Commits zu einem zusammenzufassen. --hard ist gefährlich für nicht committete Änderungen: Die holt nicht einmal das reflog zurück.

16. Was unterscheidet git revert von git reset?

reset setzt den Branch-Zeiger zurück und schreibt damit faktisch die Historie um. revert erzeugt einen neuen Commit, der die Änderungen des angegebenen Commits aufhebt, und schreibt nichts um.

Für veröffentlichte Commits auf einem gemeinsamen Branch ist daher revert die richtige Antwort: Die Historie der Kollegen bleibt intakt, und das Rückgängigmachen ist im Log sichtbar. Bei einem Merge-Commit müssen Sie den Haupt-Parent angeben: git revert -m 1 <hash>.

17. Wie stellen Sie Commits nach einem versehentlichen git reset --hard wieder her?

Über git reflog: Es speichert lokal die Bewegungen von HEAD und Branches (Einträge leben standardmäßig etwa 90 Tage). Sie suchen den Eintrag vor dem missglückten Befehl und kehren dorthin zurück:

git reflog
# a1b2c3d HEAD@{0}: reset: moving to HEAD~2
# 9f8e7d6 HEAD@{1}: commit: Bezahlung hinzufügen
git reset --hard 9f8e7d6

Wichtige Einschränkung: Das reflog rettet nur Committetes. Änderungen, die nie in einem Commit (oder zumindest im Stash) gelandet sind, lassen sich mit Git nicht wiederherstellen.

18. Wie verwerfen Sie Änderungen an einer Datei und nehmen sie aus dem Index?

Die modernen Befehle sind git restore app.js (Datei auf den Stand des Index zurücksetzen) und git restore --staged app.js (aus dem Index nehmen, Änderungen behalten). Früher verwendete man dafür git checkout -- app.js und git reset HEAD app.js; beides funktioniert weiterhin.

19. Was ist git stash und welche Fallstricke hat es?

git stash sichert nicht committete Änderungen vorübergehend und räumt das Arbeitsverzeichnis auf – etwa um schnell auf einen Hotfix zu wechseln. Zurück holen Sie sie mit git stash pop oder apply.

Fallstricke: Untracked Dateien werden standardmäßig nicht gesichert (dafür braucht es -u); bei pop kann es einen Konflikt geben, dann bleibt der Eintrag in der Liste; und Stashes vergisst man leicht. Für längere Arbeit ist ein Commit in einem eigenen Branch besser.

Fortgeschrittene Fragen und Teamarbeit

20. Wie finden Sie den Commit, der eine Funktion kaputt gemacht hat?

Mit git bisect – einer binären Suche durch die Historie. Sie geben einen sicher fehlerhaften und einen funktionierenden Commit an, und Git setzt Sie jeweils in die Mitte des Bereichs, bis der Verursacher nach log2(N) Schritten gefunden ist.

git bisect start
git bisect bad                 # aktuelle Version ist kaputt
git bisect good v2.3.0         # hier hat alles funktioniert
# prüfen und mit good/bad antworten, bis Git den Commit nennt
git bisect reset

Gibt es ein Prüfskript, läuft der Prozess automatisch: git bisect run npm test.

21. Warum ist git push --force gefährlich und was ist die Alternative?

--force überschreibt den Remote-Branch mit Ihrer Version, und Commits, die Kollegen zwischenzeitlich gepusht haben, verschwinden vom Server. Sicherer ist git push --force-with-lease: Es überschreibt den Branch nur, wenn er auf dem Server noch den Stand hat, den Sie beim letzten fetch gesehen haben.

Ein Force-Push ist auf dem eigenen Feature-Branch nach einem Rebase völlig normal; für main und andere gemeinsame Branches wird er üblicherweise per Branch Protection auf dem Server verboten.

22. Welche Git-Workflows kennen Sie?

GitHub Flow: ein Hauptbranch, der jederzeit deploybar ist, und kurzlebige Feature-Branches, die nach Review und CI per Pull Request gemergt werden. Git Flow: Branches main und develop plus feature/*, release/* und hotfix/*; passt zu Produkten mit versionierten Releases. Trunk-based Development: Alle integrieren sehr häufig in den Trunk, Unfertiges wird hinter Feature Flags versteckt.

Eine starke Antwort begründet die Wahl: Für einen Webdienst mit Continuous Deployment ist Git Flow meist überdimensioniert, für eine Bibliothek, die mehrere Versionen pflegt, dagegen gerechtfertigt.

23. Was ist ein Pull Request und was wird darin geprüft?

Ein Pull Request (bei GitLab Merge Request) ist eine Anfrage, einen Branch zu mergen; vorher durchläuft er Code-Review und automatische CI-Checks. Das ist eine Funktion der Plattform (GitHub, GitLab, Bitbucket), nicht von Git selbst.

Ein guter PR ist klein, löst eine Aufgabe, hat eine verständliche Beschreibung und ist mit dem Ticket im Tracker verknüpft. Der Reviewer achtet auf Korrektheit, Lesbarkeit, Tests und darauf, dass keine überflüssigen Dateien oder Secrets im PR gelandet sind.

24. Welche Regeln für gute Commit-Messages befolgen Sie?

Eine kurze Betreffzeile (bis 50–72 Zeichen) im Imperativ – „E-Mail-Validierung hinzufügen“ –, danach eine Leerzeile und ein Body, der das „Warum“ erklärt, nicht das „Was“ (was sich geändert hat, zeigt der Diff). Viele Teams nutzen Conventional Commits: feat:, fix:, docs:, refactor:.

Solche Messages ermöglichen es, ein Changelog zu generieren, per git log --grep schnell das Gesuchte zu finden und auch nach Jahren die Motive hinter Änderungen nachzuvollziehen.

25. Was tun Sie, wenn Sie versehentlich ein Passwort ins Repository gepusht haben?

Zuallererst das Secret widerrufen und neu ausstellen: Es ist bereits kompromittiert, selbst wenn Sie es eine Minute später entfernen (Klone, Forks, Caches). Danach die Datei aus dem Tracking nehmen, in .gitignore eintragen und bei Bedarf die Historie mit Tools wie git filter-repo bereinigen – mit anschließendem Force-Push und Vorwarnung ans Team.

Hier prüft der Interviewer Ihre Prioritäten: Wer mit dem Umschreiben der Historie beginnt und die Rotation des Schlüssels vergisst, antwortet falsch.

So bereiten Sie sich auf Git-Fragen vor

Am zuverlässigsten ist es, die Antworten nicht auswendig zu lernen, sondern jedes Szenario in einem Test-Repository selbst durchzuspielen: einen Konflikt erzeugen und lösen, reset --hard ausführen und sich über das reflog retten, Commits per interaktivem Rebase zusammenfassen. Im Vorstellungsgespräch gibt es zu Git oft eine praktische Aufgabe, oder Sie sollen den Commit-Graphen vor und nach einem Befehl aufzeichnen – wer das selbst gemacht hat, zeichnet die Antwort mühelos.

Hilfreich ist auch ein kurzer Git-Test zur Selbstkontrolle: Beantworten Sie ohne Hilfsmittel, was nach git rebase main oder git revert HEAD mit der Historie passiert. Wenn Sie die Frage „Was ändert sich in den drei Bereichen?“ sicher beantworten, sitzen die Grundlagen.

Fazit

Ein Git-Interview läuft fast immer auf drei Themen hinaus: das Datenmodell (Commits, Branches, HEAD, Index), die Integration von Änderungen (merge, rebase, Konflikte, fetch und pull) und das sichere Rückgängigmachen (reset, revert, reflog). Kommen noch Verständnis für Team-Workflows und Pull Requests dazu, decken Sie den Großteil der Fragen ab. All diese Szenarien, einschließlich Teamarbeit und fortgeschrittener Werkzeuge, üben Sie praktisch im Git-Kurs.