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.
(Permalink)