Skip to content

Kapitel 13: Git-Interviewfragen für Anfänger

13.1 Grundlagenfragen

📝 Frage 1: Was ist Git?

Frage: "Erklären Sie kurz, was Git ist."

Musterantwort:

Git ist ein verteiltes Versionskontrollsystem, das entwickelt wurde, um Softwareprojekte effizient zu verwalten. Es ermöglicht Entwicklern, Änderungen am Code zu verfolgen, mit anderen zusammenzuarbeiten und bei Bedarf zu früheren Versionen zurückzukehren.

Wichtige Stichpunkte:

  • ✅ Verteilt (nicht zentralisiert wie SVN)
  • ✅ Versionskontrolle (Tracking von Änderungen)
  • ✅ Teamkollaboration

📝 Frage 2: Was ist der Unterschied zwischen Git und SVN?

Frage: "Wie unterscheidet sich Git von SVN?"

Musterantwort:

Der Hauptunterschied liegt in der Architektur: Git ist verteilt (jeder Entwickler hat eine vollständige Kopie des Repositories), während SVN zentralisiert ist (ein zentraler Server). Git ist außerdem schneller bei lokalen Operationen und hat ein flexibleres Branching-System.

Vergleichstabelle (Merken!):

MerkmalGitSVN
ArchitekturVerteiltZentralisiert
GeschwindigkeitSchnell (lokal)Langsamer (Server)
BranchingLeichtgewichtigSchwergewichtig

📝 Frage 3: Was ist ein Repository?

Frage: "Was verstehen Sie unter einem Git-Repository?"

Musterantwort:

Ein Repository (kurz "Repo") ist ein Projektordner, der von Git überwacht wird. Es enthält alle Dateien des Projekts sowie den .git-Ordner, in dem die gesamte Versionshistorie gespeichert ist.

Zwei Arten:

  • Lokales Repository: Auf Ihrem Computer
  • Remote-Repository: Auf einem Server (GitHub, GitLab, etc.)

13.2 Kern-Grundbefehle

📝 Frage 4: Erklären Sie git add, git commit, git push.

Frage: "Welchen Zweck haben diese drei Befehle?"

Musterantwort:

  • git add: Fügt Änderungen aus dem Working Directory zur Staging Area hinzu (Vorbereitung für Commit).
  • git commit: Speichert die Änderungen aus der Staging Area permanent in das lokale Repository.
  • git push: Lädt die lokalen Commits in das Remote-Repository hoch (für Teammitglieder sichtbar).

Drei-Bereiche-Erklärung:

Working Directory → Staging Area → Repository → Remote
     (git add)        (git commit)       (git push)

📝 Frage 5: Was macht git pull?

Frage: "Wie funktioniert git pull?"

Musterantwort:

git pull ist eine Kombination aus zwei Befehlen:

  1. git fetch: Lädt Änderungen vom Remote-Repository herunter (ohne zu mergen).
  2. git merge: Führt die heruntergeladenen Änderungen mit dem lokalen Branch zusammen.

Sicherheitsalternative:

Besser ist es oft, git fetch und dann git merge separat auszuführen, um mehr Kontrolle zu haben.


📝 Frage 6: Was ist der Unterschied zwischen git merge und git rebase?

Frage: "Wann würden Sie merge vs. rebase verwenden?"

Musterantwort:

  • git merge: Führt Branches zusammen und erstellt einen Merge-Commit. Die Historie bleibt erhalten, wie sie war.
  • git rebase: Verschiebt Commits auf einen neuen Basis-Commit. Die Historie wird linear (sauberer), aber es ändert die Historie (gefährlich für geteilte Branches).

Empfehlung:

  • merge für Team-Branches (sicherer).
  • rebase für lokale, noch nicht gepushte Commits (sauberere Historie).

13.3 Szenario-Fragen

📝 Frage 7: Einen Merge-Konflikt lösen

Szenario: "Sie mergen zwei Branches und erhalten einen Merge-Konflikt. Wie gehen Sie vor?"

Musterantwort:

  1. Konfliktdatei öffnen: Git markiert Konfliktstellen mit <<<<<<<, =======, >>>>>>>.
  2. Datei bearbeiten: Konfliktmarkierungen entfernen und den korrekten Code behalten.
  3. Datei zur Staging Area hinzufügen: git add <datei>.
  4. Merge abschließen: git commit -m "Merge: Konflikt gelöst".

Beispiel:

html
<<<<<<< HEAD
<h1>Version A</h1>
=======
<h1>Version B</h1>
>>>>>>> feature-branch

→ In <h1>Version B</h1> ändern und Markierungen entfernen.


📝 Frage 8: Letzten Commit rückgängig machen

Szenario: "Sie haben gerade einen Commit erstellt, aber die Commit-Nachricht ist falsch. Was tun?"

Musterantwort:

Wenn der Commit noch nicht gepusht wurde:

bash
git commit --amend -m "Neue, korrekte Nachricht"

Wenn der Commit bereits gepusht wurde:

  • ❌ Nicht amend verwenden!
  • Stattdessen einen neuen Commit erstellen, der den Fehler korrigiert.

📝 Frage 9: Datei versehentlich gelöscht

Szenario: "Sie haben eine Datei gelöscht und committet. Wie stellen Sie sie wieder her?"

Musterantwort:

Wenn die Datei in einem früheren Commit existierte:

bash
# 1. Commit-Hash finden, in dem die Datei noch existierte
git log --oneline -- pfad/zur/datei

# 2. Datei aus diesem Commit wiederherstellen
git checkout a1b2c3d -- pfad/zur/datei

# 3. Wiederhergestellte Datei committen
git add pfad/zur/datei
git commit -m "Restore: Datei wiederhergestellt"

13.4 Fortgeschrittene Fragen

📝 Frage 10: Was ist git stash?

Frage: "Wofür wird git stash verwendet?"

Musterantwort:

git stash speichert temporäre Änderungen (ohne Commit) und stellt das Arbeitsverzeichnis auf den letzten Commit zurück. Dies ist nützlich, wenn Sie die Arbeit unterbrechen müssen (z.B. um einen dringenden Bugfix zu machen), aber noch keinen Commit erstellen möchten.

Häufige Befehle:

bash
git stash          # Änderungen speichern
git stash list     # Alle Stashes anzeigen
git stash pop      # Neuesten Stash wiederherstellen (und löschen)
git stash apply    # Neuesten Stash wiederherstellen (ohne löschen)

📝 Frage 11: Was ist der Unterschied zwischen git reset und git revert?

Frage: "Wann verwendet man reset vs. revert?"

Musterantwort:

  • git reset: Verschiebt den HEAD auf einen früheren Commit. Dies löscht nachfolgende Commits (gefährlich!).
  • git revert: Erstellt einen neuen Commit, der die Änderungen eines alten Commits rückgängig macht. Die Historie bleibt erhalten (sicherer für Teams).

Empfehlung:

  • reset: Nur für lokale, noch nicht gepushte Commits.
  • revert: Für bereits geteilte Commits (z.B. in main).

📝 Frage 12: Was ist ein "detached HEAD"?

Frage: "Was bedeutet 'detached HEAD' und wie behebt man es?"

Musterantwort:

Ein detached HEAD bedeutet, dass HEAD direkt auf einen Commit zeigt (nicht auf einen Branch). Änderungen in diesem Zustand gehen verloren, wenn man den Branch wechselt.

Behebung:

bash
# 1. Neuen Branch erstellen (um Änderungen zu retten)
git checkout -b temp-branch

# 2. Zurück zu einem normalen Branch wechseln
git checkout main

13.5 Interview-Tipps

🎯 Tipp 1: Kernkonzepte verstehen

Wichtige Konzepte, die Sie erklären können sollten:

  • Working Directory, Staging Area, Repository (Drei-Bereiche)
  • Branches (Isolation, Parallelentwicklung)
  • Merge vs. Rebase (Vor- und Nachteile)
  • Remote-Repositories (Zusammenarbeit)

🎯 Tipp 2: Praktische Erfahrung mitbringen

Im Interview könnten Sie gefragt werden:

  • "Zeigen Sie mir, wie Sie einen Branch erstellen und mergen."
  • "Wie lösen Sie einen Merge-Konflikt?"

Vorbereitung:

Üben Sie die wichtigsten Befehle (siehe Anhang) und simulieren Sie Szenarien (z.B. Konfliktlösung).


🎯 Tipp 3: Ehrlich sein

Wenn Sie etwas nicht wissen:

"Das habe ich noch nicht verwendet, aber ich würde es so angehen: ..."

Besser als:

Etwas zu erfinden und dabei falsch zu liegen.


🎯 Tipp 4: Branching-Strategien kennen

Häufige Frage:

"Welche Branching-Strategie verwenden Sie in Ihrem Team?"

Mögliche Antwort:

"Wir verwenden GitHub Flow: main ist die Produktionsbranch, neue Features werden in feature/...-Branches entwickelt und über Pull Requests gemergt."


📝 Zusammenfassung

In diesem Kapitel haben Sie gelernt:

  • Grundlagenfragen (Was ist Git? Unterschied zu SVN?)
  • Kern-Grundbefehle (add, commit, push, pull)
  • Szenario-Fragen (Konfliktlösung, Commit rückgängig machen)
  • Fortgeschrittene Fragen (stash, reset vs. revert, detached HEAD)
  • Interview-Tipps (Kernkonzepte, Praxis, Ehrlichkeit)

Nächstes Kapitel: Wir werden weiterführende Lernswege behandeln (Git-Interna, CI/CD, etc.).



Copyright © 2024 Git-Tutorial für Anfänger

Frei für alle Anfänger