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.

c'est ton avis et tu fais bien ce que tu veux. git-stash ne m'a pas convaincu. chacun voit midi à sa porte. :)

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)

redondant? pas vraiment. 'git add .' ajoute uniquement les fichiers créés/modifiés et pas ceux supprimés. 'git commit -am' ajoute les fichiers qui ont été modifiés et supprimés, mais les nouveaux fichiers qui n'ont jamais été trackés ne sont pas affectés. dans les 2 cas le .gitignore est respecté.

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) on ne peut pas juste « le refaire à la main » puisque son SHA sera différent changé, 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.

oui je l'utilise en connaissance de cause. peut-être devrais-je préciser que chaque chose que je mets sur mon shaarli n'est pas à prendre pour argent comptant (surtout pour git, je ne suis qu'un sysadmin). enfin surtout je compte sur toi pour venir me dire que ce que j'utilise ne te correspond pas. ^^

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^"

c'est une meilleure pratique de faire des alias git oui, ça je te l'accorde.

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.

c'est pourtant ce que je fais quand je reviens sur ma branche pour bosser dessus. ce n'est pas parce que je fais un gros commit sale (mais temporaire) pour passer à autre branche que je procède comme ça pour les autres commits que je release.

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.

tu n'en manques pas une pour te mettre sur un piedestal. ce qui me rappele ce shaarlink: https://jeekajoo.eu/links/?K6_NuQ

dis, un jour on fera la paix?