Git-Workflow verbessern: Wichtige Befehlszeilen-Tools und GUIs

Vergleiche alltägliche Git-CLI-Befehle mit hilfreichen Tools wie lazygit, delta, tig und GUI-Clients für Überprüfungs- und Historiearbeit.

Git-Workflow verbessern: Wichtige Befehlszeilen-Tools und GUIs

Git, als schnelles, skalierbares, verteiltes Revisionskontrollsystem, bildet das Rückgrat moderner Softwareentwicklungs-Workflows. Während seine Kern-Befehlszeilenschnittstelle eine robuste Kontrolle über die Versionierung bietet, kann das Verständnis und die Nutzung seines umfangreichen Befehlssatzes zusammen mit spezialisierten Befehlszeilen-Tools und grafischen Benutzeroberflächen (GUIs) die Produktivität erheblich steigern und komplexe Aufgaben vereinfachen. Dieser Leitfaden konzentriert sich auf Tools, die echte Workflow-Probleme lösen: saubere Commits vorbereiten, Historie lesen, Diffs überprüfen und mit Branches umgehen, ohne den Überblick über Änderungen zu verlieren.

Sie benötigen nicht jedes Tool hier. Wählen Sie die kleinste Menge, die Ihre tägliche Arbeit klarer macht.

Kern-Git-Workflow: Wichtige Befehlszeilen-Operationen

Git bietet einen reichhaltigen Befehlssatz, kategorisiert in hochrangige "Porcelain"-Befehle für Endbenutzer und niedrigrangige "Plumbing"-Befehle für Skripterstellung und interne Objektverwaltung. Hier konzentrieren wir uns auf die wesentlichen Porcelain-Befehle für tägliche Aufgaben.

Erste Schritte mit einem Repository

Um ein neues Projekt zu starten oder einem bestehenden beizutreten, sind diese Befehle Ihr Ausgangspunkt:

  • Ein neues Git-Repository initialisieren:
    git init
    
  • Ein vorhandenes Repository von einer URL klonen:
    git clone <url>
    

Änderungen verwalten (Staging und Committen)

Bevor Sie committen, verwendet Git einen "Staging-Bereich" (auch als Index bekannt), um Änderungen vorzubereiten. Dies gibt Ihnen eine feinkörnige Kontrolle darüber, was in jeden Commit aufgenommen wird.

  • Bestimmte Dateien zum Staging-Bereich hinzufügen:
    git add <datei>
    
  • Alle unverfolgten und geänderten Dateien zum Staging-Bereich hinzufügen:
    git add .
    
  • Teile einer Datei interaktiv stagen (Hunks):
    git add -p
    
  • Eine Datei verschieben oder umbenennen:
    git mv <alt> <neu>
    
  • Eine Datei aus dem Arbeitsverzeichnis und dem Staging-Bereich löschen:
    git rm <datei>
    
  • Eine Datei aus der Git-Verfolgung entfernen, ohne sie vom Dateisystem zu löschen:
    git rm --cached <datei>
    
  • Eine bestimmte Datei aus dem Staging-Bereich entfernen:
    git reset <datei>
    
  • Alle Änderungen aus dem Staging-Bereich entfernen:
    git reset
    
  • Den Status Ihres Arbeitsverzeichnisses und Staging-Bereichs überprüfen:
    git status
    

Sobald Änderungen gestaged sind, können Sie sie committen:

  • Gestagte Änderungen committen (öffnet Editor für Nachricht):
    git commit
    
  • Gestagte Änderungen mit einer Nachricht committen:
    git commit -m 'Ihre Commit-Nachricht'
    
  • Alle verfolgten, nicht gestagten Änderungen direkt committen (überspringt git add für Modifikationen):
    git commit -am 'Ihre Commit-Nachricht'
    

Branching und Merging

Branches sind grundlegend für Gits verteilte Natur und ermöglichen parallele Entwicklung. Merging und Rebasing sind Möglichkeiten, Änderungen zu integrieren.

  • Zu einem vorhandenen Branch wechseln:
    git switch <name>
    # ODER (ältere Syntax)
    git checkout <name>
    
  • Einen neuen Branch erstellen und zu ihm wechseln:
    git switch -c <name>
    # ODER (ältere Syntax)
    git checkout -b <name>
    
  • Alle lokalen Branches auflisten:
    git branch
    
  • Branches nach letztem Commit-Datum auflisten:
    git branch --sort=-committerdate
    
  • Einen lokalen Branch löschen (nur wenn gemerged):
    git branch -d <name>
    
  • Einen lokalen Branch zwangsweise löschen (auch wenn nicht gemerged):
    git branch -D <name>
    
  • Einen Branch in Ihren aktuellen Branch mergen:
    git merge <zu-merge-branch>
    
  • Einen Branch als einzelnen Commit in Ihren aktuellen Branch mergen (Squash-Merge):
    git merge --squash <zu-merge-branch>
    git commit -m 'Squashed Commit-Nachricht'
    
  • Ihren aktuellen Branch auf einen anderen rebasen (schreibt Historie um):
    git rebase <basis-branch>
    

Zusammenarbeit mit Remotes

Git zeichnet sich in kollaborativen Umgebungen aus, indem es Änderungen von und zu entfernten Repositories pusht und pullt.

  • Ein neues Remote-Repository hinzufügen:
    git remote add <name> <url>
    
  • Ihren aktuellen Branch zu seinem Remote-Tracking-Branch pushen:
    git push
    
  • Einen neuen Branch zum ersten Mal pushen und Upstream setzen:
    git push -u origin <name>
    
  • Force Push (mit äußerster Vorsicht verwenden, überschreibt Remote-Historie):
    git push --force-with-lease
    
  • Änderungen von einem Remote abrufen (integriert sie nicht in Ihre lokalen Branches):
    git fetch origin main
    
  • Änderungen abrufen und dann in Ihren aktuellen Branch mergen:
    git pull origin main
    # ODER (wenn Tracking-Branch gesetzt ist)
    git pull
    
  • Änderungen abrufen und dann Ihren aktuellen Branch rebasen:
    git pull --rebase
    

Historie und Diffs inspizieren

Zu verstehen, was sich geändert hat und wer diese Änderungen vorgenommen hat, ist entscheidend für Debugging und Überprüfung.

  • Eine Zusammenfassung aller gestagten und nicht gestagten Änderungen anzeigen:
    git diff HEAD
    
  • Diff nur der gestagten Änderungen anzeigen:
    git diff --staged
    
  • Diff nur der nicht gestagten Änderungen anzeigen:
    git diff
    
  • Commit-Logs anzeigen (verschiedene Optionen):
    git log # Vollständiges Log
    git log --graph # ASCII-Art-Baum der Historie
    git log --oneline # Prägnante Einzeiler pro Commit
    git log <datei> # Historie einer bestimmten Datei
    git log --follow <datei> # Historie inklusive Umbenennungen
    git log -G <muster>
    
    git log -G <muster> findet Commits, bei denen sich die Anzahl der passenden Zeilen geändert hat. Zum Beispiel ist git log -G "timeout" -- app/ nützlich, wenn Sie wissen müssen, wann sich die Timeout-Behandlung in einem Service-Verzeichnis geändert hat.

Befehlszeilen-Tools, die Git einfacher machen

Die einfache Git-CLI sollte Ihre Basis bleiben. Zusätzliche Tools sind am besten, wenn sie den Zustand leichter erkennbar machen, nicht wenn sie verbergen, was Git tut.

lazygit bietet Ihnen eine interaktive Terminal-Benutzeroberfläche zum Stagen von Hunks, Durchsuchen von Commits, Lösen einfacher Konflikte und Pushen von Branches. Es ist nützlich, wenn Sie eine visuelle Übersicht wünschen, aber dennoch im Terminal arbeiten.

tig ist eine schnelle Text-Benutzeroberfläche zum Durchsuchen der Historie. Es ist besonders gut auf Servern oder entfernten Entwicklungsmaschinen geeignet, wo eine vollständige Desktop-GUI nicht verfügbar ist.

delta verbessert Git-Diffs mit Syntax-Highlighting und klarerer Anzeige von verschobenen Zeilen. Nach der Installation ist eine gängige Einrichtung:

git config --global core.pager delta
git config --global interactive.diffFilter "delta --color-only"

Überprüfen Sie die Dokumentation von delta für Optionen, die zu Ihren Terminalfarben passen. Halten Sie die Konfiguration zunächst klein, damit die einfache Git-Ausgabe leicht wiederherstellbar ist.

Für die Repository-Bereinigung oder das Entfernen sensibler Historie wird git-filter-repo im Allgemeinen gegenüber dem älteren git filter-branch bevorzugt. Behandeln Sie jede Historie-Umschreibung als Team-Operation. Es ändert Commit-IDs und zwingt alle, die das Repository verwenden, sorgfältig zu resynchronisieren.

Wann eine GUI das bessere Werkzeug ist

Eine GUI kann die richtige Wahl sein, um breite Änderungen zu überprüfen, Branches zu vergleichen oder Git-Konzepte jemandem zu vermitteln, der visuell denkt. Tools wie GitHub Desktop, GitKraken, Sourcetree, Fork und IDE-Integrationen können das Stagen und die Historie-Inspektion erleichtern.

Verwenden Sie eine GUI, wenn sie Ihnen hilft, konkrete Fragen zu beantworten:

  • Welche Dateien wurden in diesem Branch geändert?
  • Welche Commits sind einzigartig für diesen Branch?
  • Was hat diese Umbenennung oder Refaktorisierung tatsächlich berührt?
  • Welche Seite eines Konflikts sollte ich behalten?

Verwenden Sie keine GUI als Ersatz für das Verständnis grundlegender Befehle. Wenn ein Push fehlschlägt, ein Rebase konfliktiert oder CI einen detached Commit auscheckt, sind die Fehlermeldungen und Wiederherstellungsschritte immer noch Git-Konzepte.

Ein praktisches Setup für die tägliche Arbeit

Ein ausgewogener Workflow könnte so aussehen:

git status
git add -p
git diff --staged
git commit -m "Health-Check-Endpunkt hinzufügen"
git pull --rebase
git push -u origin feature/health-check

Verwenden Sie dann git log --oneline --graph --decorate --all oder eine GUI, um zu inspizieren, wie der Branch in die breitere Historie passt.

Wenn Sie Aliase hinzufügen, halten Sie sie offensichtlich:

git config --global alias.st status
git config --global alias.lg "log --oneline --graph --decorate --all"
git config --global alias.unstage "restore --staged"

Aliase sollten Befehle verkürzen, die Sie bereits verstehen. Vermeiden Sie Aliase, die destruktive Aktionen ausführen, es sei denn, der Name ist unmissverständlich.

Abschließende Erkenntnis

Verwenden Sie die Git-CLI für die Operationen, die Sie unter Druck verstehen müssen: status, diff, add, commit, branch, fetch, pull, push, merge und rebase. Fügen Sie Terminal-Tools oder GUIs hinzu, wo sie die Sichtbarkeit verbessern. Der beste Workflow ist nicht der mit den meisten Tools; es ist der, der es Ihnen ermöglicht, Ihre Änderungen klar zu sehen, bevor Sie sie teilen.