J'ai toujours été d'accord avec le mantra de Mercurial 1 , cependant, maintenant que Mercurial est fourni avec l'extension rebase et que c'est une pratique populaire dans git, je me demande si cela pourrait vraiment être considéré comme une "mauvaise pratique", ou du moins assez mauvais pour éviter d'utiliser. En tout cas, je suis conscient que le rebasage est dangereux après avoir poussé.
OTOH, je vois l'intérêt d'essayer de regrouper 5 commits en un seul pour le rendre plus nift (spécialement dans une branche de production), cependant, personnellement, je pense qu'il serait préférable de pouvoir voir des validations partielles pour une fonctionnalité où certains l'expérimentation est faite, même si ce n'est pas aussi astucieux, mais voir quelque chose comme "J'ai essayé de le faire de manière X mais ce n'est pas aussi optimal que Y après tout, le faire Z en prenant Y comme base" serait à mon humble avis une valeur intéressante pour ceux qui étudient la base de code et suivez le train de pensée des développeurs.
Mon point de vue très opiniâtre (comme stupide, viscéral, biaisé) est que les programmeurs aiment rebaser pour cacher les erreurs ... et je ne pense pas que ce soit bon pour le projet.
Ma question est donc la suivante: avez-vous vraiment trouvé utile d'avoir de tels «validations organiques» (c'est-à-dire un historique intact) dans la pratique?, Ou inversement, préférez-vous exécuter des commits astucieux et ne pas tenir compte du processus d'expérimentation des programmeurs ?; quel que soit celui que vous avez choisi, pourquoi cela fonctionne-t-il pour vous? (avoir d'autres membres de l'équipe pour garder l'historique, ou bien le rebaser).
1 par analyse Google DVCS , dans Mercurial "History is Sacred".