Git Aliases
Git nutze ich jetzt mehr als sieben Jahre, kratze aber oft immer noch nur an der Oberfläche. Insbesondere habe ich lange Zeit die sehr nützlichen Aliase für Git-Kommandos nicht genutzt, die die Tipparbeit sehr vereinfachen können.
Pro Git sagt im Kapitel 2.7 “Git Aliases” eigentlich alles dazu, was man wissen mus: git config alias.NAME COMMAND macht git NAME zu einem Alias für git COMMAND. Ist COMMAND kein Git-Kommando, ist ihm ein ! voranzustellen. git config --global statt git config macht den Alias für alle Repositories des Benutzers verfügbar, git config --system tut das systemweit.
Zwei Beispiele will ich noch geben:
git publish für Webseiten
In meinem “Webseiten-Workflow” ist es regelmäßig erforderlich, Änderungen aus dem test-Zweig eines Repositorys in den master-Zweig zu übernehmen und diesen dann zu pushen. Dafür kann man jedes Mal git checkout master; git merge test; git push; git checkout test tippen, und so habe ich das auch lange Zeit gemacht. Man kann aber auch einen Alias publish definieren und dann schlicht (und gut merkbar) git publish verwenden, um die Änderungen aus dem test-Zweig zu “veröffentlichen”.
Der Alias lässt sich anlegen durch git config alias.publish '!git checkout master; git merge test; git push; git checkout test' oder durch Einfügen des folgenden Abschnitts in die config-Datei im .git-Verzeichnis des Repositorys:
[alias]
publish = "!git checkout master; git merge test; git push; git checkout test\n"
git refresh zur Übernahme von Upstream-Änderungen
Wer in einem Github-Projekt mitarbeitet, wird regelmäßig das entsprechende Repository forken und dann Änderungen als Pull Requests zur Überprüfung stellen. Ich habe dann in meinem lokalen Repository jeweils zwei Remotes konfiguriert: origin ist mein eigenes Github-Repository, der Fork, und upstream das Repository des Projekts. Außerdem habe ich in meinem Repository einen upstream-Branch, der dem master-Branch des Projekt-Repositorys folgt.
Will ich Änderungen aus dem Projekt-Repository in meinen master-Zweig übernehmen, gehören dazu folgende Schritte:
- den upstream-Zweig mit dem master-Zweig des Projekt-Repositorys zu aktualisieren
- den upstream-Zweig in meinem geforkten Repository veröffentlichen
- den upstream-Zweig in meinen master-Zweig mergen
- meinen master-Zweig veröffentlichen
Das erfordert also folgende Kommandos:
git checkout upstream
git pull
git push origin
git checkout master
git merge upstream
git push origin
git remote prune origin
(Das letzte Kommando entfernt lokale Tracking-Branches, die in meinem Github-Repository schon nicht mehr existieren.)
Ein Alias dafür ist echt praktisch:
git config alias.refresh '!git checkout upstream; git pull; git push origin; git checkout master; git merge upstream; git push origin; git remote prune origin'
git refresh führt dann alle dargestellten Kommandos nacheinander aus.
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt