L'historique des versions est-il vraiment sacré ou vaut-il mieux rebaser?

26

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

dukeofgaming
la source
pourriez-vous indiquer où il est indiqué comme «mantra de Mercurial»?
gnat
Maintenant que vous le mentionnez, je pense que cela vient en fait du code d'analyse DVCS de Google.google.com/p/support/wiki/DVCSAnalysis (mais le fait demeure)
dukeofgaming

Réponses:

22

L' Histoire est sacrée, le Présent ne l'est pas. Vous pouvez diviser votre "arborescence" DVCS en deux parties:

  • Le passé / l'historique qui contient une vue précise de la façon dont vous avez atteint l'état actuel du code. Cette partie de l'histoire grandit avec le temps

  • Le présent sur quelle partie vous travaillez actuellement pour faire évoluer votre code. Cette astuce la plus grande partie de l'histoire a à peu près toujours la même taille.

Chaque code que vous avez publié ou utilisé d'une manière ou d'une autre fait partie du passé . Le passé est sacré car il faut pouvoir reproduire une configuration ou comprendre ce qui a introduit une régression. Tu ne réécriras jamais le passé . Dans git, vous ne réécrivez généralement rien une fois qu'il est dans master: master est la partie passée de l'histoire. Dans Mercurial, vous avez ce concept de phase publique qui garde la trace de la partie passée de votre "arbre" et renforce son immuabilité.

La partie actuelle du code est l'ensemble de modifications sur lequel vous travaillez actuellement. La branche de fonctionnalité que vous essayez de rendre utilisable, sans bug et correctement refactorisée. C'est parfaitement bien de le réécrire c'est même une bonne idée car cela rend la partie passée plus jolie, simple et utilisable. Mercurial suit cela dans la phase de projet .

Alors oui, veuillez rebaser si cela améliore votre historique. Mercurial vous empêchera de vous tirer une balle dans le pied si vous rebasiez des choses que vous ne devriez pas.

Marmoute
la source
Maintenant, j'ai mieux aimé votre réponse
dukeofgaming
7

Toutes les erreurs ne sont pas du type que vous devez masquer - par exemple, j'ai une fois accidentellement validé un fichier binaire dans mon référentiel. La falsification de l'historique n'est mauvaise que lorsque le défaut n'est pas exclusivement dans l'historique lui-même, comme les fichiers validés qui ne devraient pas l'être.

DeadMG
la source
1
Donc, vous ne rebaserez jamais pour rendre un commit plus "logique"?
dukeofgaming
7

La révision du code est beaucoup plus facile lorsqu'il y a un grand changement cohérent par opposition à beaucoup de petits changements dépendants.

Lorsque je travaille sur une nouvelle fonctionnalité, j'aime faire beaucoup de petits changements dans ma branche. Lorsque je suis prêt à soumettre le correctif, je réduis ces petites validations en une seule grande validation qui représente tout le nouveau code requis pour cette fonctionnalité. C'est là que le rebase est utile.

D'un autre côté, rebaser n'est pas conseillé si les commits n'ont rien à voir les uns avec les autres. Les ajouts de fonctionnalités multiples doivent être des validations distinctes (et idéalement provenir de branches distinctes).

chrisaycock
la source
4
il existe de nombreux outils qui rendent la révision du code de plusieurs modifications connexes assez triviale, donc en soi, je n'achète pas cela comme une réponse
jk.
4
Quelle différence y a-t-il entre l'examen de la différence entre la révision de base et la révision complète de la fonctionnalité, et l'examen de la validation unique de cet ensemble de validations redéfini? Cela va sembler identique si la re-base a fait son travail correctement!
Mark Booth
3
Ce que vous décrivez ici va directement à l'encontre des conseils du wiki Mercurial . Les petits ensembles de modifications "évidemment corrects" sont préférés pour les révisions. Réduire une branche de fonctionnalité en un seul ensemble de modifications n'est pas normal dans Mercurial - je l'ai vu recommandé plus souvent dans Git où git rebase -ivous permet de le faire facilement et de manière sélective. L'équivalent Mercurial le plus proche est histedit .
Martin Geisler
9
Je suis totalement en désaccord. Au cours des deux dernières années, nous avons utilisé un outil pour les révisions de code, et il n'y avait rien de plus que je détestais recevoir un grand ensemble de modifications de plus de 30 fichiers soumis pour examen. Il est beaucoup plus facile d'obtenir de nombreux petits changements. Par exemple, j'ai renommé cette classe en xyz car elle reflète mieux la responsabilité modifiée. J'ai ajouté la méthode nn car j'en aurai besoin pour bla. Il est beaucoup plus facile de gérer de plus petites critiques.
Pete
3
J'ai beaucoup entendu cette idée dans la communauté git consistant à regrouper de nombreux commits en un avant de passer au dépôt officiel, mais cela ne m'a jamais été utile. Je préfère de beaucoup les petits commits avec des messages significatifs. Comme d'autres l'ont noté, vous pouvez faire une différence sur plusieurs ensembles de modifications.
Chris Sutton
4

Votre question décrit l'histoire comme un ensemble de modifications de code ordonnées et demande si les validations organiques induisent ou non les futurs lecteurs dans le processus de développement. Pourtant, en tant qu'ingénieur de publication / intégration, je ne considère pas souvent l'histoire comme du code. Je suis plus absorbé par l'histoire que raconte mon histoire, les connaissances institutionnelles qu'elle conserve et si elle me permet ou non de déboguer rapidement les problèmes.

Je ne pense pas que les workflows organiques fonctionnent bien, même les miens. Les qualités que j'apprécie à propos du DVCS lorsque je code - des succursales bon marché, des validations rapides, des sauvegardes sur la télécommande tôt et souvent - ne sont pas ce que j'apprécie en tant que gestionnaire d'intégration de mon entreprise . Question que je git rebase, git merge, git diffet git applybeaucoup plus souvent dans ce rôle que git addou git commit. Des outils comme rebaseme permettent de transformer le code qui m'est donné de quelque chose qui fonctionne en quelque chose qui peut être maintenu.

Les validations illogiques ou vagues ne sont pas utiles, mais elles sont facilement faciles à écrire de manière organique, lorsque la principale préoccupation est de faire fonctionner le code, et non de le distribuer à d'autres. S'engage comme Case 15: Fixed a problem, ou Refactored <cranky legacy feature>fait grincer des dents mon entretien-même, même quand je les écris. Aucun, cependant, n'induit la rage du black-out comme les commits "incrémentiels". Considérez cette branche thématique qu'un développeur m'a remise l'autre jour:

$ git log production..topic --oneline
f9a1184 incremental update
156d299 incremental commits
e8d50b0 new incremental updates
511c18c incremental updates, refactor
1b46217 incremental upgrade
9e2b3b8 incremental update
fa68a87 incremental update

Ces choses sont mauvaises. C'est comme un DVCS conçu pour le Dr Faustus. Je vais vous donner un contrôle de source rapide et facile. Vous me donnez est l'âme de votre mainteneur de code. Tous les commissions paresseux sont des actes égoïstes. Beaucoup d'entre nous les écrivent, mais nous devons également à notre avenir une histoire logique, reproductible et déboguable. Nous ne pouvons pas faire cela sans moyen rebase.

En ce qui concerne les expériences qui ont échoué, pourquoi ne pas les décrire dans nos messages de validation (nouvellement vierges)? Dans un an, je n'ai pas besoin d'un extrait à moitié fini. Je veux juste un enregistrement de la tentative avortée, et peut-être une courte explication si je pense que je suis assez stupide pour l'essayer à nouveau. Il y a beaucoup de workflows réussis dans le monde, mais j'ai du mal à penser à une raison pour laquelle j'engagerais sciemment du code cassé dans une base de code de production.

Christophe
la source
Très belle réponse, des motivations claires sur pourquoi rebaser
dukeofgaming
2

Rien ne devrait être sacré, mais assurez-vous d'avoir de bonnes raisons pour ce que vous faites. Le remodelage est extrêmement puissant lorsqu'il est utilisé correctement, mais comme avec tout outil puissant, il peut être déroutant et causer des problèmes s'il est utilisé avec négligence.

Personnellement, je trouve très utile de rebaser une branche de fonctionnalité locale contre trunk (ou branche de développement principale) avant d'exécuter les tests finaux et de fusionner la fonctionnalité dans la branche principale. De cette façon, je peux gérer tous les conflits de fusion, etc. avant de fusionner.

harald
la source
1

À mon humble avis, les expériences appartiennent généralement à des étagères ou à des branches temporaires, pas à des lignes de base. Si vous suivez cela, il ne devrait pas y avoir de problème, car toutes les validations seront logiquement valables et ajouteront de la valeur.

Codeur
la source
Ce que vous dites, c'est que vous préférez travailler avec des branches plutôt que de modifier une branche de base (c.-à-d. Maître / par défaut, production / version, vX.X, etc.)?
dukeofgaming