Git: verwendet ihr Aliase?

[paedubucher]

Eine kleine Showcase-Umfrage für diejenigen, die häufig Git (oder von mir aus: Mercurial) verwenden. Definiert ihr Aliase für die häufigsten Git-Befehle? Ich selber habe eine ganze Reihe definiert:

Code: Alles auswählen

alias gin='git init'
alias gcl='git clone'
alias gpl='git pull'
alias gps='git push'
alias gcm='git commit'
alias gst='git status --short'
alias gad='git add'
alias grm='git rm'
alias gco='git checkout'                                                      
alias gbr='git branch'                                                        
alias gdf='git diff'                                                          
alias glg='git log'                                                           
alias gmv='git mv'                                                            
alias gbl='git blame'                                                         
alias gmg='git merge'

Wie handhabt ihr das so?

[Meillo]

Ich verwende keine Shell-Aliase, sondern git-Aliase.

Aus meiner ~/.gitconfig:

Code: Alles auswählen

[alias]
        st = status
        ci = commit
        br = branch

Das sind diejenigen, die ich staendig verwende.


Nachtrag:

Ein Alias wie `glg = git log' wuerde mir eher wenig bringen, da ich natuerlichartige Woerter leichter tippe als irgendwelche Zeichenkombinationen. Zwei- und dreibuchstabige Woerter lassen sich eh schnell tippen. D.h. ich versuche in erster Linie die langen, mehrsilbigen Woerter abzukuerzen.

`st' und `ci' waren anfangs nur Gewohnheitsabkuerzungen, die ich von Mercurial uebernommen habe. Sie machen mich aber schneller. `git log' tippe ich aber ungefaehr gleich schnell wie `glg', weil ich letzteres eher umstaendlich zu tippen finde, waehrend ersteres kurze Worter sind, die normalen Silben entsprechen und demnach die Art von Woertern sind, die man fast immer tippt und deshalb auch gut kann.

[JTH]

Ich verwende eigentlich alle Werkzeuge, auch git, möglichst ohne große eigene Veränderungen am Standardverhalten (außer sowas wie Zugangsdaten o.ä. natürlich). Also auch ohne Aliase. Damit kann ich die mir wichtigen Werkzeuge überall, ohne große Konfiguration, gleich schnell und effektiv benutzen. Auch wenn das in meiner Situation im Moment grad nicht relevant ist, in der Vergangenheit wars regelmäßig hilfreich, kein besonderes Setup gewohnt zu sein – während Kollegen dann schon kurz darüber gestolpert sind, wenn ll nicht als Alias definiert war.

Mein Weg, Tipparbeit zu sparen, ist eher die Shellhistorie. Str + R und 2, 3, 4 Buchstaben und ich hab die vor kurzem benutzte Kommandozeile wieder, die ich suche.

Ein Alias wie `glg = git log' wuerde mir eher wenig bringen, da ich natuerlichartige Woerter leichter tippe als irgendwelche Zeichenkombinationen.

Interessanter Punkt. Das müsste man mal (lern-)psychologisch näher untersuchen

[Meillo]

Ich verwende eigentlich alle Werkzeuge, auch git, möglichst ohne große eigene Veränderungen am Standardverhalten (außer sowas wie Zugangsdaten o.ä. natürlich). Also auch ohne Aliase. Damit kann ich die mir wichtigen Werkzeuge überall, ohne große Konfiguration, gleich schnell und effektiv benutzen. Auch wenn das in meiner Situation im Moment grad nicht relevant ist, in der Vergangenheit wars regelmäßig hilfreich, kein besonderes Setup gewohnt zu sein – während Kollegen dann schon kurz darüber gestolpert sind, wenn ll nicht als Alias definiert war.

Da zeigen sich grosse Unterschiede, ob eine Person eigentlich nur auf dem eigenen System arbeitet oder staendig an unterschiedlichen Systemen ist.

Ein Alias wie `glg = git log' wuerde mir eher wenig bringen, da ich natuerlichartige Woerter leichter tippe als irgendwelche Zeichenkombinationen.

Interessanter Punkt. Das müsste man mal (lern-)psychologisch näher untersuchen

Eher neurologisch, da das IMO vor allem eine Sache des Muskelgedaechtnisses ist. Normale Silben (also zumeist ein Abwechseln von Vokalen und Konsonanten) plus typische Kombinationen (wie `sch', `st', `ei', usw.) uebt man staendig (zumindest wenn man, wie ich, viel natuerlichsprachlichen Text tippt). Daher kann man sie besser. Die Finger wissen schon wie das geht. Dazu gibt's vielleicht Studien ueber Pianisten, die gewohnte Muster schneller spielen koennen als ungewohnte, einfach weil das Muskelgedaechtnis dort schon trainiert ist.

Der andere, rein mechanische Aspekt bei der Tippgeschwindigkeit sind Fingerwege und Hand-/Fingerwechsel. Die haengen natuerlich auch vom Tastaturlayout ab.

Aber ich will gar nicht weiter in diese Richtung abtauchen. Mir geht es nur darum, dass es fuer mich wenig Sinn macht, einen Alias anzulegen, fuer kurze Woerter, die eine natuerliche Buchstabenabfolge haben, weil ich die sowieso schon besonders schnell tippen kann. `git log' ist ein gutes Beispiel dafuer.


Sinvoll finde ich Aliase, um haeufig genutzte Befehle kuerzer zu machen (wie bei `git st' satt `git status'), oder um mir Sonderzeichen zu ersparen (wie bei `git stuno' satt `git st -uno'), oder um mir einen langen Befehl, den ich immer identische verwende, nicht merken zu muessen (wie bei `git unpushed' statt `git log --branches --not --remotes --no-walk --decorate --oneline').

[oln]

Code: Alles auswählen

[alias]
        st = status
        ci = commit
        br = branch

Sieht bei mir ähnlich aus:

Code: Alles auswählen

co = checkout
ci = commit -a
st = status -s
br = branch
hist = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short
alias = ! git config --get-regexp ^alias\. | sed -e s/^alias\.// -e s/\ /\ =\ /

co+ci kommt bei mir noch aus alten SVN-Zeiten.

[Meillo]

@oln: Mit `commit -a' solltest du aufpassen. In meiner Erfahrung haben Entwickler, die standardmaessig `commit -a' verwenden, oft unsaubere Commits. Meist sind es Entwickler, die von SVN und Co. kommen und nicht wirklich mit git arbeiten, sondern nur ihren Code reinhauen.

Mit `commit -a' verbaut man sich auch manche wertvollen git-Moeglichkeiten wie `git add -p'.

... aber es kommt natuerlich darauf an, fuer was und in welchen Projekten du git einsetzt. Ich wollte nur darauf hinweisen.


(Ach ja, `git co' habe ich natuerlich auch. )

[paedubucher]

Ich verwende eigentlich alle Werkzeuge, auch git, möglichst ohne große eigene Veränderungen am Standardverhalten (außer sowas wie Zugangsdaten o.ä. natürlich). Also auch ohne Aliase. Damit kann ich die mir wichtigen Werkzeuge überall, ohne große Konfiguration, gleich schnell und effektiv benutzen. Auch wenn das in meiner Situation im Moment grad nicht relevant ist, in der Vergangenheit wars regelmäßig hilfreich, kein besonderes Setup gewohnt zu sein – während Kollegen dann schon kurz darüber gestolpert sind, wenn ll nicht als Alias definiert war.

Ich kann das sehr gut nachvollziehen! Für mein Setup als Lehrer verwende ich auch keine Aliase, damit ich beim Vorzeigen immer die kompletten Befehle eingeben muss. Da bin ich aber beim privaten Arbeiten auf dem Rechner aber auch schon einmal in die Falle getappt und habe mein gad getippt.

Meillos Anmerkung mit den Silben finde ich auch interessant. git log tippt sich kaum langsamer als glg. Andererseits habe ich meine Aliase mittlerweile im Muskelgedächtnis.

[oln]

@oln: Mit `commit -a' solltest du aufpassen. In meiner Erfahrung haben Entwickler, die standardmaessig `commit -a' verwenden, oft unsaubere Commits. Meist sind es Entwickler, die von SVN und Co. kommen und nicht wirklich mit git arbeiten, sondern nur ihren Code reinhauen.

Das ist mir bewusst.

`git add -p'.

Dannst du mir dafür einen konkreten Anwendungsfall schildern?

[JTH]

Der andere, rein mechanische Aspekt bei der Tippgeschwindigkeit sind Fingerwege und Hand-/Fingerwechsel.

Ja, Unterschiede von Tastaturen lassen sich mit keinem Alias umgehen – außer man hätte als „Alias“ seine eigene Tastatur immer in der Tasche. Fremde Tastaturen sind anstrengend

Da zeigen sich grosse Unterschiede, ob eine Person eigentlich nur auf dem eigenen System arbeitet oder staendig an unterschiedlichen Systemen ist.

Das stimmt wohl. Trotzdem komm ich mir auch Zuhause mit meinen hier zwei „eigenen“ Bash-Aliasen fast rebellisch vor

`git add -p'.

Dannst du mir dafür einen konkreten Anwendungsfall schildern?

Du arbeitest an größeren Änderungen in einer Datei, bemerkst währenddessen einen kleineren (vllt Rechtschreib-) Fehler an andererer Stelle in selbiger. Mit einem flinken git add -p oder direkt git commit -p kann man den Fehler ohne Probleme als eigenständigen, kleinen Commit beheben. Wenn es die persönliche Präferenz oder das Projekt gerne so haben, dass jede eigenständige, für sich abgeschlossene und funktionale Änderung nachvollziehbar in einem eigenen Commit, mit sinnvoller Beschreibung, stecken. Kann in der Zukunft immer mal das Nachvollziehen von Änderungen, ein git bisect etc. erleichtern, wenn man keine irrelevanten Änderungen in einem Commit hat.

[oln]

Du arbeitest an größeren Änderungen in einer Datei, bemerkst währenddessen einen kleineren (vllt Rechtschreib-) Fehler an andererer Stelle in selbiger. Mit einem flinken git add -p oder direkt git commit -p kann man den Fehler ohne Probleme als eigenständigen, kleinen Commit beheben. Wenn es die persönliche Präferenz oder das Projekt gerne so haben, dass jede eigenständige, für sich abgeschlossene und funktionale Änderung nachvollziehbar in einem eigenen Commit, mit sinnvoller Beschreibung, stecken. Kann in der Zukunft immer mal das Nachvollziehen von Änderungen, ein git bisect etc. erleichtern, wenn man keine irrelevanten Änderungen in einem Commit hat.

Danke für die Ausführung. Allerdings ist bei mir, master/main geschützt. Also darf dort keiner rein pushen. Bei den MergeRequests benutzen wir hier immer "squash commits". Somit wäre auch da die Nachvollziehbarkeit weg oder?

[Meillo]

Du arbeitest an größeren Änderungen in einer Datei, bemerkst währenddessen einen kleineren (vllt Rechtschreib-) Fehler an andererer Stelle in selbiger. Mit einem flinken git add -p oder direkt git commit -p kann man den Fehler ohne Probleme als eigenständigen, kleinen Commit beheben. Wenn es die persönliche Präferenz oder das Projekt gerne so haben, dass jede eigenständige, für sich abgeschlossene und funktionale Änderung nachvollziehbar in einem eigenen Commit, mit sinnvoller Beschreibung, stecken. Kann in der Zukunft immer mal das Nachvollziehen von Änderungen, ein git bisect etc. erleichtern, wenn man keine irrelevanten Änderungen in einem Commit hat.

Danke für die Ausführung. Allerdings ist bei mir, master/main geschützt. Also darf dort keiner rein pushen. Bei den MergeRequests benutzen wir hier immer "squash commits". Somit wäre auch da die Nachvollziehbarkeit weg oder?

Ja, wenn man Squasht, dann macht das wenig Sinn.

Vom Prinzip her nutze ich `git add -p' halt immer dann wenn ich von den Aenderungen in einer Datei nur einen Teil committen moechte. Das kann auch vorkommen, wenn ich nachtraeglich bei einem `rebase -i' (nur lokal!) einen Commit splitten will. Wenn die genau Form von Einzelcommits wenig wichtig ist, dann ist das recht egal. Dann kann ich auch das `commit -a' verstehen.