Die 25 wichtigsten Git-Interviewfragen und -antworten für alle Levels

Grundlegende Git-Interviewfragen

Wenn du Git erst seit Kurzem nutzt, werden grundlegende Interviewfragen oft Basis-Konzepte und -Anwendungsfälle abdecken. Falls du dein Wissen auffrischen willst, wirf einen Blick auf DataCamps Kurs Introduction to Git.

Was ist ein Git-Repository?

Ein Git-Repository speichert die Dateien und die Änderungshistorie eines Projekts und ermöglicht Versionskontrolle, indem es Anpassungen über die Zeit nachverfolgt. Es kann lokal in einem Ordner auf deinem Gerät oder auf einer Online-Plattform wie GitHub liegen. So können Nutzende zusammenarbeiten, zu früheren Versionen zurückkehren und die Entwicklung mit Befehlen wie commit, push und pull effizient steuern.

Wie funktioniert Git?

Git protokolliert Änderungen an Dateien und Verzeichnissen eines Projekts und erstellt Schnappschüsse des jeweiligen Zustands. Du kannst Änderungen nachvollziehen, Branches für parallele Entwicklung anlegen, Branches zusammenführen und bei Bedarf zu früheren Ständen zurückkehren. Damit fördert Git Zusammenarbeit und stellt eine wirkungsvolle Versionskontrolle in Softwareprojekten sicher.

Was ist git add?

Mit dem Befehl git add stellst du Änderungen für den nächsten Commit bereit. Er bereitet Modifikationen, Ergänzungen oder Löschungen in deinem Working Directory vor und markiert sie für die kommende Commit-Aufnahme. Wichtig: Dieser Befehl führt noch keinen Commit aus, sondern stellt nur fürs Staging bereit.

Was ist git push?

Mit git push lädst du Inhalte aus deinem lokalen Repository in ein Remote-Repository hoch. Dabei werden bereits committete Änderungen vom lokalen in einen entfernten Speicher übertragen, typischerweise auf einem Server wie GitHub oder GitLab. So können Teams Änderungen teilen und gemeinsam am selben Projekt arbeiten.

Mehr über Git push und pull erfährst du in unserem separaten Tutorial.

Was ist git status?

Der Befehl git status zeigt dir den aktuellen Zustand des Repositories. Er informiert darüber, welche Dateien geändert wurden, welche fürs nächste Commit gestaged sind und welche untracked sind. So behältst du den Überblick über deinen Fortschritt und siehst, was noch committed oder gestaged werden muss.

Was ist ein Commit in Git?

Ein Commit ist ein Schnappschuss der Änderungen an Dateien im Repository zu einem bestimmten Zeitpunkt. Wenn du in Git committest, speicherst du den aktuellen Stand deiner Dateien und kannst eine aussagekräftige Nachricht hinzufügen, die die Änderungen erklärt (empfohlen).

Jeder Commit erhält eine eindeutige Kennung, mit der sich die Änderungshistorie im Repository nachverfolgen lässt. Commits sind zentral für die Versionskontrolle: Sie ermöglichen das Zurücksetzen auf frühere Zustände, das Überprüfen der Historie und die Zusammenarbeit, indem Aktualisierungen geteilt werden.

Sieh dir DataCamps Git Cheat Sheet für deine Interviewvorbereitung an

Was bedeutet Branching in Git?

Branching bezeichnet das Abzweigen von der Hauptentwicklungslinie (typischerweise main, früher master), um an neuen Features, Fixes oder Experimenten zu arbeiten, ohne den Hauptcode zu beeinflussen. So können mehrere parallele Entwicklungslinien im selben Repository koexistieren.

Jeder Branch repräsentiert eine eigene Entwicklungslinie mit eigenen Commits, sodass verschiedene Features oder Fixes gleichzeitig entstehen können. Branching fördert Zusammenarbeit, Experimentieren und Struktur im Projekt, denn Änderungen eines Branches können nach Abschluss und Tests wieder in den Hauptzweig zusammengeführt werden.

Was ist ein Konflikt in Git?

Konflikte entstehen, wenn verschiedene Beitragende widersprüchliche Änderungen am selben Teil einer Datei vornehmen, typischerweise während Merge- oder Rebase-Vorgängen. Git kann solche Konflikte nicht automatisch auflösen, sodass du sie manuell bereinigen musst.

Um einen Konflikt zu lösen, öffne die betroffene Datei — Git markiert die Konfliktbereiche mit den Markern <<<<<<<, ======= und >>>>>>>. Bearbeite die Datei, behalte die korrekte Version, entferne die Marker und führe dann aus:

git add <resolved-file>
git commit

Was ist Merging in Git?

Merging ist ein grundlegender Git-Vorgang für Zusammenarbeit und das Integrieren von Änderungen aus verschiedenen Branches. Dabei werden Änderungen aus unterschiedlichen Branches in einem einzelnen Branch zusammengeführt, typischerweise im Hauptzweig (z. B. master oder main).

Ein Merge integriert die Änderungen eines Branches in einen anderen und erzeugt einen neuen Commit, der die Historien beider Branches kombiniert. Mehr darüber, wie du Merge-Konflikte in Git löst, findest du in unserem separaten Tutorial.

Fortgeschrittene Git-Interviewfragen

Was ist ein Remote in Git?

Ein Remote ist ein Repository auf einem Server oder einem anderen Rechner, das der Zusammenarbeit und dem Teilen von Code dient. Es ist der zentrale Ort, an den Entwickler ihre lokalen Änderungen pushen und von dem sie Änderungen anderer pullen.

Remotes werden typischerweise auf Plattformen wie GitHub, GitLab oder Bitbucket eingerichtet. Sie ermöglichen verteilte Entwicklung und erleichtern Teamarbeit, indem sie einen gemeinsamen Speicherort zum Ablegen und Synchronisieren des Codes bieten.

Wie machst du einen bereits gepushten, öffentlichen Commit rückgängig?

Mit git revert <commit-hash> kannst du einen bereits gepushten, öffentlichen Commit rückgängig machen.

So gehst du Schritt für Schritt vor:

1. Ermittle den Commit, den du rückgängig machen willst, anhand seines Hashes. Nutze git log, um die Historie zu sehen und den passenden Hash zu finden.

2. Verwende dann git revert gefolgt vom Commit-Hash, um einen neuen Commit zu erstellen, der die Änderungen des angegebenen Commits aufhebt. Zum Beispiel:

git revert <commit-hash>

3. Git öffnet einen Editor für die Revert-Commit-Message. Passe sie bei Bedarf an, speichere und schließe den Editor.

4. Nach dem Speichern erzeugt Git einen neuen Commit, der die ursprünglichen Änderungen effektiv zurücknimmt. Dieser neue Commit wird der Historie hinzugefügt.

5. Push den neuen Commit ins Remote-Repository, um den Revert öffentlich zu machen:

git push origin <branch-name> 

Mit git revert erzeugst du einen neuen Commit, der die ursprünglichen Änderungen aufhebt, ohne die Historie umzuschreiben. Das ist sicherer als git reset oder git amend, die die Historie verändern und für Teammitglieder, die bereits gepullt haben, Probleme verursachen können.

Was ist git stash?

git stash speichert temporär Änderungen im Working Directory, die noch nicht bereit für einen Commit sind. So kannst du Modifikationen sichern, ohne sie zu committen.

Das ist nützlich, wenn du den Branch wechseln musst, deine Änderungen aber weder verlieren noch committen willst. Später kannst du die gespeicherten Änderungen wieder anwenden oder aus dem Stash-Stack "poppen", um weiter daran zu arbeiten.

Was ist git reflog?

git reflog zeigt die Referenz-Logs an. Diese protokollieren Änderungen am HEAD-Zeiger und die Historie der ausgecheckten Commits. Du erhältst eine chronologische Liste jüngster Aktionen im Repository, darunter Commits, Checkouts, Merges und Resets.

Das Reflog hilft, verlorene Commits oder Branches wiederzufinden und die Abfolge der Aktionen nachzuvollziehen.

Wie lässt du einen bestehenden Git-Branch einen Remote-Branch tracken?

Verwende den Befehl git branch mit der Option --set-upstream-to oder -u gefolgt vom Namen des Remote-Branches.

Die Syntax sieht so aus:

git branch --set-upstream-to=<remote-name>/<branch-name>

oder

git branch -u <remote-name>/<branch-name>

Expertenfragen zu Git

Wie verwaltest du mehrere Konfigurationen für verschiedene Projekte in Git?

Nutze git config mit den Flags --global, --system oder --local, um Einstellungen auf unterschiedlichen Ebenen zu setzen. Alternativ kannst du in der Git-Konfiguration includeIf verwenden, um je nach Repository-Pfad spezifische Setups einzubinden.

Wie gehst du mit großen Dateien in Git um?

Große Dateien können Repository-Größe und Performance belasten. Verwende Git LFS, um große Dateien außerhalb des Git-Repositories zu speichern und im Repo nur leichte Zeiger darauf abzulegen. Das reduziert die Größe und verbessert die Performance. Git LFS unterstützt verschiedene Speicheranbieter und fügt sich nahtlos in Git-Workflows ein.

Wofür dient git submodule und wie aktualisierst du eines?

Mit git submodule verwaltest du externe Abhängigkeiten innerhalb eines Git-Repositories. Du kannst externe Repositories als Submodule in dein Hauptrepository einbinden. Das ist nützlich, wenn du externen Code nutzen willst, ihn aber getrennt vom Hauptcode halten möchtest.

So aktualisierst du ein Submodule:

1. Wechsle ins Verzeichnis des Submodules innerhalb deines Hauptrepositories.

2. Nutze git fetch, um die neuesten Änderungen aus dem Remote des Submodules zu holen.

3. Wenn du auf den neuesten Commit des vom Submodule verfolgten Branches aktualisieren willst, verwende git pull.

4. Alternativ kannst du mit git checkout auf einen bestimmten Commit oder Branch wechseln.

5. Nachdem das Submodule auf dem gewünschten Stand ist, committe die Änderungen im Hauptrepository, damit der aktualisierte Submodule-Stand dort festgehalten wird.

Was ist git cherry-pick und wann setzt du es ein?

git cherry-pick wendet einen bestimmten Commit aus einem Branch auf einen anderen an, ohne den gesamten Branch zu mergen.

git cherry-pick <commit-hash>

Praktisch ist das auch, wenn ein Commit versehentlich im falschen Branch gelandet ist: Cherry-picke ihn in den richtigen und revertiere ihn im falschen.

Was ist git bisect und wofür wird es genutzt?

git bisect ist ein Debugging-Tool, das mittels binärer Suche den Commit findet, der einen Bug eingeführt hat. Statt Commits manuell nacheinander zu prüfen, markierst du einen Commit als "good" (bugfrei) und einen als "bad" (mit Bug). Git checkt dazwischenliegende Commits aus und halbiert so den Suchraum, bis der Übeltäter gefunden ist.

git bisect start
git bisect bad                # aktueller Commit enthält den Bug
git bisect good <commit-hash> # dieser ältere Commit war in Ordnung
# Git checkt einen Zwischenstand aus; du testest, dann:
git bisect good   # oder git bisect bad
# wiederholen, bis Git den ersten fehlerhaften Commit findet
git bisect reset  # kehrt am Ende zum Ausgangszustand zurück

Das ist deutlich schneller als manuelles Suchen in großen Repositories mit Hunderten Commits.

Was sind Git Hooks und wie werden sie verwendet?

Git Hooks sind Skripte, die automatisch an bestimmten Punkten im Git-Workflow ausgeführt werden. Sie liegen im Verzeichnis .git/hooks/ eines Repositories und können in jeder Skriptsprache geschrieben sein.

Es gibt zwei Typen:

• Client-seitige Hooks laufen lokal — z. B. pre-commit (läuft vor dem Erstellen eines Commits) oder commit-msg (validiert das Format der Commit-Message).

• Server-seitige Hooks laufen auf dem Remote-Server — z. B. pre-receive (läuft vor dem Annehmen gepushter Commits).

Ein häufiger Anwendungsfall ist ein pre-commit-Hook, der automatisch Linter oder Tests ausführt, bevor ein Commit erlaubt wird. So werden Codequalitätsstandards im Team durchgesetzt.

Beachte, dass Hooks beim Klonen eines Repos nicht mitkopiert werden. Teams teilen sie daher oft über separate Skripte oder Tools wie pre-commit (das Python-Paket).

Fragen zu häufig verwechselten Git-Konzepten

Was ist der Unterschied zwischen git fetch und git pull?

Der zentrale Unterschied zwischen git fetch und git pull liegt darin, was sie tun und wie sie dein lokales Repository aktualisieren.

git fetch holt Änderungen aus dem Remote-Repository in dein lokales Repository. Es aktualisiert die Remote-Tracking-Branches (z. B. origin/master), ändert aber weder dein Working Directory noch merged es in deinen aktuellen Branch. Du kannst die Änderungen also prüfen, ohne deine lokale Arbeit zu beeinflussen.

git pull holt ebenfalls Änderungen, geht aber einen Schritt weiter: Es führt fetch und anschließend merge in einem Schritt aus und integriert die Remote-Änderungen direkt in deinen aktuellen Branch.

Was macht git reset?

git reset setzt den aktuellen HEAD auf einen angegebenen Stand zurück. Du kannst damit Änderungen rückgängig machen, Dateien aus dem Staging entfernen oder den HEAD-Zeiger auf einen anderen Commit verschieben. Es gibt drei Hauptmodi von git reset:

• --soft: Setzt HEAD auf einen bestimmten Commit, behält Änderungen jedoch gestaged. Dateien bleiben im Working Directory geändert und können erneut committet werden.

• --mixed: Setzt HEAD auf einen bestimmten Commit und entfernt das Staging. Dateien bleiben geändert, sind aber nicht mehr fürs Commit vorgemerkt.

• --hard: Setzt HEAD auf einen bestimmten Commit und verwirft alle Änderungen im Working Directory und Staging-Bereich. Vorsicht: Nicht committete Änderungen gehen unwiderruflich verloren.

Wichtig: Verwende git reset --hard niemals für Commits, die bereits auf einen geteilten Remote-Branch gepusht wurden. Das überschreibt Historie und führt zu ernsthaften Problemen für Teammitglieder, die diese Commits schon gepullt haben. Nutze stattdessen für öffentliche Commits git revert.

Warum ist git push --force-with-lease gegenüber git push --force vorzuziehen?

git push --force-with-lease ist die vorsichtigere Variante des Force-Pushes im Vergleich zu git push --force, da es verhindert, dass du unbeabsichtigt Änderungen anderer im Remote überschreibst.

Mit git push --force überschreibst du den Remote-Branch unabhängig davon, ob andere seit deinem letzten Fetch Änderungen vorgenommen haben. Das kann Arbeit anderer versehentlich vernichten.

git push --force-with-lease ist sicherer: Es prüft, ob der Remote-Branch seit deinem letzten Fetch aktualisiert wurde. Falls ja, wird der Push abgelehnt und du überschreibst nichts aus Versehen.

Was ist git rebase und worin unterscheidet es sich von git merge?

git rebase und git merge integrieren beide Änderungen von einem Branch in einen anderen, aber auf unterschiedliche Weise.

• git merge kombiniert die Historien zweier Branches durch einen neuen "Merge-Commit". Das erhält die vollständige Historie von Abzweigung und Zusammenführung — gut für Transparenz und Nachvollziehbarkeit.

• git rebase verschiebt bzw. spielt Commits eines Branches auf einen anderen obenauf und erzeugt so eine lineare Historie ohne Merge-Commits. Das macht Logs übersichtlicher, schreibt aber Historie um. Deshalb gilt die goldene Regel: Rebase niemals einen Branch, auf dem andere arbeiten.

Was ist der Unterschied zwischen git clone und git fork?

Clonen erstellt eine lokale Kopie eines Remote-Repositories auf deinem Rechner. Die Verbindung zum selben Repository bleibt bestehen, und du kannst (mit Berechtigung) zurückpushen.

git clone https://github.com/user/repo.git

Forks sind der Standard-Workflow, um zu Open-Source-Projekten beizutragen, bei denen du keinen direkten Schreibzugriff auf das Original-Repo hast.

So bereitest du dich auf ein Git-Interview vor

Dein Git-Wissen und deine Erfahrung im Interview überzeugend zu präsentieren, ist entscheidend, um deine Kompetenz in Versionskontrolle und Zusammenarbeit in Softwareteams zu zeigen.

Beachte diese Tipps für die Vorbereitung, um deine Git-Kompetenzen klar zu vermitteln:

Verstehe die Git-Grundlagen

Sorge für ein solides Verständnis der Git-Grundlagen: Repositories, Branching, Merging, Commits sowie Basisbefehle wie pull, push, clone und commit. Dieses Fundament trägt das Gespräch im Interview. Hilfreich ist auch ein klares Verständnis zentraler Prinzipien der Versionskontrolle und der Unterschiede zwischen Git und anderen Systemen.

Mache dich außerdem mit gängigen Git-Methodiken wie Git Flow, GitHub Flow und GitLab Flow vertraut. Bewerte Vor- und Nachteile und erkenne, in welchen Situationen welche Methode passt.

Unser kompletter Leitfaden zu Git ist ein guter Startpunkt, um die Grundlagen zu festigen.

Sammle praktische Erfahrung

Je mehr du Git nutzt, desto besser verankerst du dein Wissen. Regelmäßiges Üben erhöht die Vertrautheit mit Befehlen und Abläufen. Integriere Git in deinen Arbeitsalltag, erstelle und merge Branches und übe das Lösen von Konflikten.

Wenn du nicht weißt, welche Projekte du für Praxis mit Git angehen sollst: Beiträge zu Open-Source-Projekten auf Plattformen wie GitHub geben dir direkten Einblick in gängige Kollaborationstools und Workflows.

Lerne typische Probleme und wie du sie behebst

Bei Git wirst du zwangsläufig auf Probleme stoßen: Merge-Konflikte, detached HEAD, Reverts oder das Wiederherstellen verlorener Commits. Das Diagnostizieren solcher Themen schärft deine Troubleshooting-Fähigkeiten und vertieft dein Verständnis der Git-Mechanik.

Indem du aktiv Fehler analysierst und behebst, gewinnst du Einblicke in Gits Innenleben und wirst sicherer und schneller in der Lösung. Das reduziert Risiken und stärkt dein Vertrauen in saubere Versionsabläufe.

Übe Mock-Interviews

Mit Probeinterviews deckst du Lücken in deinem Git-Wissen und in der Kommunikation auf und kannst deine Vorbereitung gezielt ausrichten.

Außerdem bieten Mock-Interviews die Chance, Problemlösefähigkeiten an realistischen Git-Szenarien und kleinen Coding-Aufgaben zu schärfen. Das steigert dein Selbstvertrauen und hilft dir, deine Gedanken im Gespräch klar zu formulieren.

Fazit

Git ist ein mächtiges Versionskontrollsystem, das in der Softwareentwicklung weit verbreitet ist, um Codeänderungen zu verwalten, zusammenzuarbeiten und die Projekthistorie zu pflegen. Git-Kenntnisse sind in technischen Interviews essenziell: Sie zeigen den souveränen Umgang mit Entwicklerwerkzeugen und Workflows, Teamfähigkeit und die Fähigkeit, Code in Teamumgebungen strukturiert zu managen.

Ein gutes Verständnis von Git-Konzepten und -Befehlen ermöglicht effiziente Versionspraktiken, sichert Code-Integrität und Projektkontinuität und strafft Entwicklungsprozesse. Für angehende Software Engineers und Entwicklerinnen ist Git-Wissen daher Gold wert — im Interview und für die weitere Karriere.

Fürs Weiterlernen empfehlen wir:

• Was ist Git? – Der komplette Leitfaden zu Git
• GitHub- und Git-Tutorial für Einsteiger
• GitHub Concepts
• Der komplette Git-Spickzettel