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


16

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.



1
Voulez-vous de bonnes raisons? Parce que je peux fournir une variété de raisons pour retarder la vérification du code que j'ai entendu des gens dire dans la nature, mais peu d'entre elles sont de bonnes raisons.
whatsisname

La seule raison pour laquelle je peux penser est quand une fusion échoue en raison de conflits de fusion. Mais SourceTree ne s'engage pas si cela se produit de toute façon.
Robert Harvey

Sur une note latérale: Pourquoi écrivez-vous votre propre tutoriel? bitbucket a déjà un excellent tutoriel. confluence.atlassian.com/bitbucket/…
winkbrace

@winkbrace Nous n'utilisons pas Bitbucket; nous gardons tout sur un réseau local. Je fais référence au grand tutoriel d'Atlassian , mais je voulais quelque chose d'un peu plus concis que je pourrais remettre à des gens qui étaient tout nouveaux sur Git et le contrôle de version. C'est vraiment plus une introduction et une procédure "c'est comment et pourquoi vous vous engagez / push / pull / etc" pour que les gens puissent commencer.
David K

Réponses:


26

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.


Vraisemblablement, vous créez des branches de fonction et ne fusionnez pas chaque petit changement dans la branche principale. Il est peu probable que les fusions provoquent des conflits sur une branche de fonctionnalité à moins que plusieurs personnes travaillent sur la même classe sur la même branche de fonctionnalité.
Robert Harvey

4
@RobertHarvey Oui, mais je fusionne sans doute fréquemment la branche principale dans ma branche. Il y a une supposition cachée dans votre commentaire que différentes fonctionnalités toucheront naturellement différentes classes / modules, mais tout le monde n'a pas de chance. Par (mal) fortune, vous avez quelque part une classe de Dieu que tous ceux qui font quelque chose doivent toucher, et vous ne pouvez pas y faire grand-chose. Il existe également des fonctionnalités transversales (mettre à niveau une bibliothèque à cause de laquelle une ligne de code sur 10 doit être modifiée ...) Je connais l'argument "essayez de ne pas y arriver", mais que faire si vous y êtes déjà? Mieux vaut prévenir que guérir.

2

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.


2

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.