Essentielle Git Befehle

von

Die Kurzfassung

Die Dokumentation für Git ist zwar sehr umfangreich und komplett aber nicht alle Befehle braucht jeder. Deshalb hier mein Überblick über die für mich sinnvollsten Befehle. Sie sind keinesfalls vollständig, ich verweise hier auf die offizielle Website des Git-Projekts.

Durchgeführt habe ich die Befehle auf der CLI in Visual Studio Code.

  • git init
  • git status
  • git log
  • git diff
  • git add
  • git commit
  • git branch
  • git switch
  • git revert
  • git reset
  • git checkout
  • git merge
  • git stash
  • git stash pop

Die Befehlsabfolge

Auf der Kommandozeile gibt es eine Menge Befehle die dazu dienen die Übersicht über das aktuelle Projekt nicht zu verlieren. Ohne ein Git-Repository kurz Repo funktioniert natürlich gar nichts. Das heißt im aktuellen Verzeichnis ist zuerst mit

git init

Git davon mitzuteilen was es überhaupt überwachen soll. Was macht git init? Git legt einen, im Explorer versteckten (mit Punkt voran) Ordner an, der die benötigten Dateien enthält. Alle im Projektverzeichnis enthalten Dateien werden mit

git status

erstmal angezeigt und es werden auch hilfreiche Hinweise gegeben. Der aktuelle Branch, ob die Dateien tracked oder untracked sind und ob Commits anstehen. Zudem ist es hilfreich vor dem Initialisieren den Status abzufragen weil es gilt:

Kein Git-Repo innerhalb eines Repos

Als nächstes ist Git mitzuteilen welche Dateien zu überwachen sind. Das erfolgt mit dem Kommando – Achtung „nicht komma-getrennt“

git add file1.txt file2.txt
git add .

wobei der Punkt als quasi Joker für alle Dateien dient. Will ich nur eine einzige Datei überprüfen lassen hänge ich den Dateiname mit Dateiendung an den Befehl an. Die Files wurden in die Staging-Area verschoben. Das ist die Zwischenstufe vor dem Commit. Ich kann verschiedene Dateien ändern und in die Staging-Area verschieben und wenn ich alle fertig habe mit einem Commit zur Verfügung stellen. Aus diesem Staging-Bereich gib ich Dateien wieder zurück mit dem Befehl

git restore --staged

Ist alles fertig wird Comitted. Commit heißt die Dateien werden mit Metainformationen versehen. Das hat den Zweck zu einem früheren Zustand des Projekts zurückzukehren. Und zwar für alle Dateien im aktuellen Verzeichnis, die Gestaged wurden. Selbstverständlich muss ich nicht alle Dateien auf einmal commiten, sondern schiebe auf mehrere Staging-Vorgänge die Dateien in den Commit.

git commit -am "Hier kommen die Infos"

versieht den Commit mit einer -m Message, also einer Nachricht, die aussagekräftig ist. Will ich die Staging-Prozedur überspringen (bei neuen Dateien zB) setze ich vor das -m noch ein a (steht für add) und mache beides auf einmal. Die Datei muss aber zumindest erstmalig zur Überwachung hinzugefügt werden, weil sie ja sonst untrackted ist und als nicht von Git beobachtet wird.

Habe ich mich bei der Message verschrieben kann ich einmalig verwenden

git commit --amend

Wenn richtig konfiguriert öffnet der Editor ein Fenster mit der Commit-Message die ich ändern kann. Sollte Vim als Message Editor eingestellt sein – unbedingt ändern mit

git config --global core.editor "code --wait"

Einer der wichtigsten Befehle listet das aktuelle Geschehen auf. Daraus ist der eindeutige Hash ersichtlich, auf welchen branch der HEAD zeigt sowie die Commit-Message und lautet

git log --oneline

Die Anzeige dazu auf der CLI

6db49d2 (HEAD -> master) add File

Soweit so fertig.

Der Weg zurück ist vielfältig

In Git gibt es einige Wege das Verzeichnis zu einem früheren Zeitpunkt wiederherzustellen. Der erste und vielleicht geläufigste erstellt einen neuen Commit auf Basis eines früheren Zustands wieder her.

git revert <hashwert>

macht genau das. Es öffnet sich ein VI-Editor Fenster in dem man die Message eingibt. Den Editor verlässt man wieder mit Shift : und den Befehlen w für write sowie q für quit. Sollte der Editor nicht VS-Code sein. Diese Variante ist im Collaboration-Workflow zu wählen.

Der zweite Befehl löscht die vorangegangenen unwiderruflich und kann mit dem Zusatz zählend vom HEAD weg ergänzt werden und sieht folgendermaßen aus:

git reset --hard HEAD~1/Hash-Wert

wirft den letzten Commit weg und schiebt den HEAD um eins nach hinten. Das geht auch mit der Option –soft und setzt ihn auf die Staging-Area.

Während der Bearbeitung einer Datei kann ich mit dem Befehl

git checkout <dateiname>.<dateiendung>

die gerade bearbeitete Datei zurück zum letzten Commit setzten ohne Staging oder Sonstiges.

git restore filename1.txt

ist wie git switch ebenfalls neu. Restore ohne Zusatz stellt den Zustand zum letzten Commit zurück. Ein Undo quasi. Es ist dasselbe wie git checkout HEAD filename.txt Es bringt mich auch immer zum aktuellen Zustand des letzten Commits zurück.

git restore --source HEAD~2 filename.txt

stellt den Zustand bzw. den HEAD der Datei zwei Commits in die Vergangenheit. Es bleiben aber mit git log alle Commits erhalten. Es schreibt quasi die Vergangenheit nicht neu. Achtung alle ungestagten Änderungen sind weg und mit einem neuen Commit sind auch alle anderen Commits weg, weil der HEAD ja auf dem neuen Commit steht.

Branches

Ein neuer Branch wird mit dem Kommando erstellt:

git checkout -b <branchname>

Die neuere Variante wird mit dem branch/switch Kommando erstellt wobei der Schalter -c gleich in den branch wechselt und die gebräuchlichere Methode darstellt.

git switch -c <branchname>

mit checkout Branchname kann ich immer den Zweig wechseln. Wenn ich mit Änderungen am alternativen Branch fertig bin gehe ich wieder in den Master-Branch und hole mir den anderen Zweig „herein“. Das ist der gängige Weg, es ginge auch umgekehrt.

Aus dem Master-Branch heraus

git merge <branchname>

migriert der alternative Branch in den Master. Danach ist immer ein neuer Commit zu erstellen.

Mehr zu Branches

Die branch/switch-Befehle sind vielfältig und dabei auch schon lokal – also ohne Kollaboration mit zB Github – ein wenig verwirrend.

git branch -v

zeigt alle branches an. Ein Stern verweist wo der HEAD-Pointer gerade steht. Mit 

git switch <branchname>

wechsle ich den HEAD in den benannten branch und kann dort Änderungen durchführen.

Immer git add vor dem Branchwechsel

Alles was nicht gestaged ist verursacht Fehlermeldungen. Es gibt auch die Möglichkeit des Stashing aber dazu ein eigener Artikel.

git branch -D <branchname in dem ich mit nicht befinde>

löscht den branch und wird nach erfolgtem merge gemacht. Den aktuellen branch kann ich auch umbenennen mit

git branch -m <neuerbranchname>