Je me reconnais dans pas mal des problèmes mentionnés, et je suis plutôt fier, car je connais (et j'utilise) la plupart de ces "astuces" Par contre, je ne les applique pas tout le temps, car c'est parfois prise de tête (genre tu fais un commit sur la mauvaise branche, c'est ch.... à "déplacer", alors tant pis pour la consistance des branches, il restera dessus ).

Le process dont j'ai toujours peur quand je dois le faire, c'est le rebase/squash ^^ Ca finit toujours par produire un truc qu'il ne faut pas, juste parce que je me plante dans ma résolution des merges ou autre. Une vraie plaie C'est dans ces cas là typiquement que je copie tout le répertoire de travail, je crée une nouvelle branche, et je colle le répertoire précédent dedans (il doit y avoir moyen de faire "mieux" et plus efficace en demandant à git de créer un patch entre l'index courant et une référence, puis d'appliquer ce patch (ou le stasher) au bon endroit, mais bon...

Merci pour le partage, j'ai mis dans mes bookmark le lien car je sais déjà qu'il reservira
ça me permettra sans doute du coup de monter en compétence pour mieux gérer les problèmes.

Je me targue de connaître assez bien git
Une fois qu'on a bien compris la modélisation on devient assez confortable pour ne plus créer d'état inconsistant et aider les noob à dépatouiller les leurs
Sachant que le plus gros problème de git selon moi se sont les implémentations graphiques du type TortoiseGit et autres intégration IDE. La plupart gèrent le version control d'une manière totalement générique et peu adaptée à Git, quand elle n'est pas carrément calquée sur SVN. Ça entrave complètement la courbe de progression et la compréhension. (ex: qu'est-ce qu'il se passe quand je fais un `git pull`, et qu'est-ce qui fait qu'un truc qui a l'air aussi simple peut mettre le bronx sur ma branche).

Un site "tuto interactif" qui m'a mis les idées au clair il y a quelques années et que je conseille souvent aux juniors, c'est learngitbranching.js.org/

Moi je suis un grand spécialiste du

sudo rm -r fucking-git-repo-dir

On a une policy pour ne pas faire de commit sur master (tout via pull-request sur une branche, classique) et parfois j'oublie de changer de branche et fais un push sur master.
Alors je supprime tout et je recommence 😁

Vous utilisez quoi comme client Git?
Moi ceux intégrés à VS Code ou VisualStudio, je déteste les lignes de commande, c'est fini linux (pour moi) 😁

J'utilise principalement la ligne de commande et le support git intégré à vscode (pour le changement de branche, commits, diff, etc. les opérations basiques en gros).

Le stash est clairement ce qui me sauve régulièrement de problèmes potentiels quand je pull ;) Je devrai d'ailleurs configurer git pour qu'il le fasse automatiquement, ça m'évitera d'avoir des merge commits en pagaille (surtout dans le cas de nos articles, où on bosse avec Latex à plusieurs, et mes collègues ont la mauvaise habitude de ne faire des retours à la ligne qu'à la fin des paragraphes, ce qui fait que le moindre changement provoque typiquement un conflit).

Vu de ma fenêtre, quand je vois galérer des gens avec git c'est parce qu'ils ont appris à `git pull`. Je conseille à tout les gens que je croise de ne jamais pull, jamais. À la place tu `git remote update` et tu review l'état du bousin avec `tig --all` (ou tig remote/branch si c'est un gros repos).

Ensuite en fonction de ce que tu vois tu rebase, tu stash, tu merges... mais t'es pas soumis aux aléas de pull. Essayez, ça change la vie.