Pourquoi ne commettez-vous pas immédiatement les modifications fusionnées?

Mon bureau utilise Git et SourceTree pour notre contrôle de version. Cela est dû au fait que lorsque j'ai rejoint, il n'y avait aucun contrôle de version et SourceTree était le seul système que j'avais jamais utilisé. Je ne suis en aucun cas un expert, mais je suis le plus expérimenté de mes collègues, donc je suis l'expert de facto chargé d'enseigner à tout le monde à utiliser correctement Git et à corriger les erreurs qu'ils font.

Je fais un tutoriel qui passe par Git et SourceTree et explique chaque étape du processus. Dans le processus Pull, la boîte de dialogue SourceTree vous permet de sélectionner l'option "Valider les modifications fusionnées immédiatement". Je comprends ce que cela fait et pourquoi c'est utile. Ce que je ne comprends pas, c'est pourquoi personne ne voudrait utiliser cette fonctionnalité.

Quelqu'un pourrait-il expliquer pourquoi vous ne voudriez jamais que vos modifications fusionnées soient validées automatiquement? J'essaie de comprendre le raisonnement afin que je puisse mieux expliquer l'utilité de la fonctionnalité et avoir une idée des pièges à surveiller à l'avenir.

Modifier: je ne crois pas que ma question soit un double de la question liée. La question connexe demande généralement à quelle fréquence s'engager. Je demande pourquoi on choisirait de ne pas utiliser une fonctionnalité spécifique liée à la validation des fusions dans SourceTree.

Je ne voudrais pas utiliser cette fonctionnalité.

Le fait qu'il n'y ait pas eu de conflits signifie à peu près que les modifications fusionnées dans ma branche ne sont pas à peu près dans les mêmes lignes de code que celles que j'ai faites. Cela ne signifie pas que ces modifications sont compatibles avec mes modifications. Cela ne signifie pas que le code sera compilé, que le code fonctionnera ou que les tests réussiront.

En d'autres termes, en utilisant cette option, je me retrouve potentiellement avec une fausse validation de code qui peut ne pas être en bon état et qui nécessite une nouvelle validation pour être corrigée. Comme je suis en train de faire ce travail de toute façon, et que je ne devrais jamais pousser cette fausse amont commettre, même pas par erreur (Dieu ne plaise, une personne peut alors fusionner que dans une autre branche!), Je ne vois aucune raison pour créer cette validation dans la première endroit.

Après une fusion, des modifications peuvent être apportées aux fichiers du référentiel local. Ces modifications ne sont pas automatiquement validées dans le local, sauf si vous définissez "Valider les modifications fusionnées immédiatement".

Si vous ne définissez pas cette option, les fichiers apparaissent dans SourceTree en tant que modifications non validées.

C'est parce que Git lui-même ne s'engage pas sauf si vous le lui dites explicitement, et SourceTree est une interface graphique Git. L' option «Valider les modifications fusionnées immédiatement» n'est pas tant une option, mais un raccourci de commande.

Ainsi, la raison pour laquelle vous ne souhaitez pas utiliser cette fonctionnalité est évidente: vous souhaitez effectuer la validation manuellement, ou pas du tout.

Supposons que vous tiriez master vers votre branche de fonctionnalité. Un collègue travaille sur une branche de fonctionnalité différente. Ce collègue a une histoire de casser des choses. La fusion contient des modifications du code commun partagé apportées par ce collègue. Ainsi, vous - ainsi que le reste de l'équipe - ne commettez pas de modifications fusionnées tant que vous n'êtes pas sûr qu'aucune modification apportée par ce collègue n'affectera votre travail.

Tout simplement parce qu'il n'y a aucune bonne raison - en théorie - de ne pas utiliser cette fonctionnalité, en réalité, il peut y avoir un certain nombre de bonnes raisons. En ce qui concerne votre tutoriel, je dirais simplement que "99 fois sur 100, c'est l'option que vous souhaitez utiliser". Je ne pense pas que vous ayez vraiment besoin d'entrer dans les détails pour ne pas l'utiliser, surtout si les autres sont nouveaux dans le contrôle de version. Tout dépend de la profondeur de votre intention pour le didacticiel.

Si vous utilisez un hook post commit pour pousser automatiquement vos commits (comme dans /programming//a/7925891/6781678 ), vous pourriez avoir besoin de cette option pour éviter de pousser certains commit de qualité douteuse.

Je n'utiliserais jamais non plus.