Interviewfragen zu Git mit Antworten

Beispielfragen

Ein paar Fragen aus jedem Level mit richtiger Antwort und Erklärung.

Git · Junior

1. Was macht Git zu einem verteilten Versionskontrollsystem?
   ▸Antwort zeigen

   Richtige Antwort: Jeder Klon hat die ganze Historie und kann offline arbeiten

   Ein Klon enthält jeden Commit, man kann also ohne Server committen, branchen und die Historie ansehen. Ein Remote wie GitHub ist nur eine weitere Kopie, mit der sich das Team synchronisiert.

2. Durch welche drei Hauptbereiche bewegt sich eine Datei in Git?
   ▸Antwort zeigen

   Richtige Antwort: Working Tree, Staging Area (Index), Repository

   Man bearbeitet Dateien im Working Tree, wählt mit git add (dem Index) aus, was in den nächsten Commit kommt, und git commit speichert diesen Schnappschuss im Repository.

3. Was macht git add file.js?
   ▸Antwort zeigen

   Richtige Antwort: Merkt den aktuellen Inhalt der Datei für den nächsten Commit vor

   git add kopiert den aktuellen Zustand der Datei in den Index. Bearbeitet man die Datei danach erneut, sind die neuen Änderungen erst nach einem weiteren git add vorgemerkt.

4. Was speichert ein Git-Commit?
   ▸Antwort zeigen

   Richtige Antwort: Einen Schnappschuss des Projekts plus Autor, Nachricht und Elternteil

   Konzeptionell ist jeder Commit ein vollständiger Schnappschuss (unveränderte Dateien werden wiederverwendet, nicht dupliziert) mit Metadaten und einem Verweis auf sein Elternteil. Diffs werden berechnet, wenn man sie anfordert.

Git · Middle

1. Was macht git rebase main auf einem Feature-Branch?
   ▸Antwort zeigen

   Richtige Antwort: Spielt die Commits des Branches auf dem neuesten main neu ab

   Jeder Feature-Commit wird auf der neuen Basis erneut angewendet, wodurch neue Commits mit neuen Hashes entstehen. Das Ergebnis ist eine lineare Historie, als hätte man den Branch vom heutigen main aus begonnen.

2. Was ist die „goldene Regel“ des Rebasens?
   ▸Antwort zeigen

   Richtige Antwort: Keine Commits rebasen, auf denen andere aufbauen

   Rebasen ersetzt Commits durch neue. Haben Teammitglieder schon die alten, weicht ihre Historie ab, und sie haben am Ende Duplikate. Den eigenen, nicht gepushten oder privaten Branch darf man gern rebasen.

3. Merge vs. Rebase, um main in einen Feature-Branch zu holen: was ist der Kompromiss?
   ▸Antwort zeigen

   Richtige Antwort: Merge behält die echte Historie; Rebase ergibt eine lineare, schreibt aber Commits um

   Merge bewahrt genau, was passiert ist, und fügt Merge-Commits hinzu; Rebase erzeugt eine saubere Linie, die leichter zu lesen und zu bisecten ist, auf Kosten neuer Hashes. Teams wählen eine Konvention.

4. Während eines Rebase stößt du auf einen Konflikt. Was ist die übliche Abfolge?
   ▸Antwort zeigen

   Richtige Antwort: Dateien korrigieren, mit git add vormerken, dann git rebase --continue

   Rebase hält beim konfliktbehafteten Commit an; ist er gelöst und vorgemerkt, geht --continue zum nächsten. --skip verwirft den aktuellen Commit ganz, --abort stellt den ursprünglichen Branch wieder her.

Git · Senior

1. Welche vier Objekttypen bilden die Objektdatenbank von Git?
   ▸Antwort zeigen

   Richtige Antwort: Blob, Tree, Commit und annotiertes Tag

   Blobs halten Dateiinhalte, Trees ordnen Namen Blobs und Subtrees zu, Commits zeigen auf einen Tree und Eltern, und annotierte Tags zeigen auf ein Objekt mit Nachricht. Branches sind Refs, keine Objekte.

2. Warum dupliziert das Umbenennen einer Datei ihren Inhalt im Git-Speicher nicht?
   ▸Antwort zeigen

   Richtige Antwort: Der Blob wird über den Inhalt adressiert; nur der Tree-Eintrag ändert sich

   Identischer Inhalt hat immer denselben Hash, wird also einmal gespeichert. Umbenennungen werden später durch Vergleich von Trees erkannt, nicht explizit festgehalten.

3. Was ist intern eine Ref in Git?
   ▸Antwort zeigen

   Richtige Antwort: Ein Name, der einen Commit-Hash speichert, etwa refs/heads/main

   Refs liegen als kleine Dateien oder in packed-refs. HEAD ist eine symbolische Ref, die auf eine andere Ref zeigt. Einen Branch zu verschieben heißt nur, einen neuen Hash in seine Ref zu schreiben.

4. Was macht git gc?
   ▸Antwort zeigen

   Richtige Antwort: Packt Objekte, entfernt unerreichbare und lässt alte Reflogs ablaufen

   Lose Objekte werden mit Deltas in Packfiles komprimiert, und von Refs und Reflogs aus unerreichbare Objekte werden nach einer Schonfrist entfernt. Git führt es automatisch aus.