Tu utilises bien les techniques que tu veux. Mais quand on donne un conseil technique il me semble qu'on a une certaine responsabilité de prévenir les destinataires des risques potentiels.
En l'occurence un git reset HEAD^ c'est pas une commande triviale à utiliser et je trouve préférable de donner les pistes permettant de corriger une erreur plutôt que simplement poser ça là en se contentant d'un « C'est trop cool [par contre démerdez vous si vous perdez des données à cause de gunwip] »
Donc j'explique pour les lecteur⋅ices qui ne savent pas : git log peut aussi servir à voir l'historique sur un dépot distant, et git reflog sert à retrouver l'historique des commits sur lesquel on est passé.
Pour la différence entre git add . et git commit -a, je trouve peu pertinent d'ajouter au dépôt des fichiers non suivis si on en a pas encore l'usage.
Ça vaut pour les .fuse_hidden qui surviennent de temps en temps dans les montages sshfs, pour les fichiers temporaires d'une librairie qu'on vient de tester et qu'on a pas encore pris le temps de mettre dans le .gitignore, pour les .Trash d'un poste qui n'a pas encore de gitignore global, voire pire ce fichier de conf avec le mot de passe de la base de donnée qui lui non plus reflete un travail en cours et qui n'est pas encore dans le gitignore, etc…
C'est ton choix, moi je préfère prévenir qu'il y a un risque que j'estime non négligeable de perte de donnée, ainsi que de pourrissement de dépôt par des données inutiles ou des fuites de mot de passe.
Pour finir ta remarque sur le piédestal est déplacée, je ne pense pas t'avoir manqué de respect personnel en critiquant ta solution technique. Au risque de me faire traiter encore une fois d'oppresseur intolérant, je te prierai de ne pas verser dans l'attaque perso sans provocation. Peut-être après on fera « la paix. »
Ah la vile cochonnerie ! Non, vraiment faites pas ça.
Pour mettre un travail en attente il y a git stash, qui n'a pour seul comportement inattendu que demander à résoudre les conflits si conflit il y a.
Ensuite au niveau de la mise en place de cette "solution" ça laisse à désirer.
Faire git add . est redondant avec l'argument -a de git commit qui a le même effet. (Sauf que ça commite pas les fichiers non suivis, mais du coup ça évite en plus de rajouter dans le dépôt des fichiers qui n'ont rien à y faire et qu'on a manqué dans le .gitignore)
Faire un alias qui efface le dernier commit, c'est un coup à perdre des données. gunwip sur la mauvaise branche et oups merde, comment je le retrouve ce commit que j'aurai pas du effacer ? (Avec git reflog si on s'en rends compte de suite, avec de la chance si on a fait d'autres trucs depuis.)
Et si on efface un commit public il faut le retrouver (heureusement ce sera plus simple qu'avec un commit local, avec git log origin/nom_de_branche on s'en sort facilement) on ne peut pas juste « le refaire à la main » puisque son SHA sera différent, il faudra faire un push -f et les contributeurs vont être perturbés. Une fois encore, si on se rend pas de suite compte de la boulette, il faut du courage.
Faire des alias bash est peu pertinent pour les commandes git simples vu que git permet de faire des alias git (et éloigne le risque d'une mauvaise frappe du coup)
git config --global alias.wip "commit -am '--wip--'"
git config --global alias.unwip "reset HEAD^"
Il faut maintenant taper git wip et git unwip, comme ça on sait que ce sont des commandes git et pas autre chose.
Mais vraiment, c'est très mal ce genre de trucs et un workflow plus robuste est de faire beaucoup de petits commits puis éventuellement y remettre de l'ordre ensuite avec un rebase interactif.
via moi-même, développeur responsable git au boulot, qui passe une part non négligeable de mon temps à rattraper les boulettes des collègues et stagiaires aventureux qui font ce genre de choses.