Supposons que nous ayons deux branches A
et B
qui ont été fourchus de master
.
Les deux branches A
et B
apportent des modifications et mettent en œuvre certains tests unitaires. Ils transmettent tous les tests actuels et nouveaux, puis sont fusionnés dans master
. Pour la simplicité, il n'y a pas de conflit de fusion.
Est-il garanti que le code résultant sur master
transmettra également les tests de l'unité?
La raison pour laquelle je pose la question, est-ce que je vois souvent des tests d'unité GITUB exécutés automatiquement une fois qu'une demande de traction est effectuée. S'ils passent, le code peut être fusionné dans master
. Cependant, je pense que master
pourrait toujours finir par des tests échoués si deux demandes de traction se casseront? J'aurais pensé qu'une meilleure solution serait:
master
, exécutez les tests de l'unité, si tout réussit, commettre la fusion.Donc, vous ne commettez jamais de code brisé en Maître.
Bien sûr Il n'y a aucune garantie. Les exemples sont légion.
mais.
Il n'est pas déraisonnable de supposer que non liée, Les changements isolés sont peu susceptibles de ne rien briser. Les améliorations de performance dans un algorithme de backend sont peu susceptibles de modifier l'interface de la base de données. C'est la même hypothèse qui sous-jacente au paradigme des contrôles non réservés/développement parallèle dont Git est un excellent exemple: j'espère que l'équipe communique bien et organise des forfaits de travail de manière à ne pas entrer en conflit ou, si cela est impossible, organise Travaux contradictoires de manière à ce que les problèmes soulevés soient prévisibles et manipulés de manière proactive. (Ensuite, idéalement, nous savent qu'une fusion naïve est cassée.)