Les conflits de fusion compliqués fréquents sont-ils un signe de problèmes?

Dans notre équipe, nous utilisons Git comme contrôle de source. Nous avons plusieurs domaines de code presque indépendants mais qui se chevauchent parfois. Dernièrement, nous avons discuté des workflows et des approches pour utiliser le contrôle de source. Une des plaintes qui se pose lorsque je préconise l’utilisation d’un flux de travaux de branche de fonctionnalités est que les personnes se heurtent souvent à des conflits de fusion compliqués qu’elles ne résolvent pas correctement. Par compliqué, je veux dire "pas évident quant à la façon de résoudre". À la lumière de cela, d’autres flux de travail sont utilisés plus activement, tels que les flux de travail basés sur le "ré-extraction".

En tant que défenseur de l'approche par branche, je ne reçois pas vraiment la plainte. Oui, vous devez garder vos branches de fonctionnalités locales à jour depuis le maître ou ailleurs, mais c'est à peu près le seul problème que je vois. Je pense que si vos fusions sont toujours compliquées et peuvent avoir des effets secondaires, alors c'est plus un problème de travail d'équipe qu'un problème de Git.

Ai-je raison de penser cela? Les conflits de fusion compliqués sont-ils un signe de bon ou de mauvais?

Ce n'est pas impossible que le problème soit votre code. Si votre base de code a beaucoup d'interrelations entre les modules, alors chaque changement aura des vrilles partout, et chaque développeur interagira avec le code de quelqu'un d'autre, ce sera un cauchemar.

J'aurais tendance à penser que vous remarqueriez cela d'une autre manière, mais il est possible que vous soyez tellement habitué à cela que vous ne le voyez plus.

Je suis habitué au workflow "fetch-rebase-push". Quel est en fait le premier flux de travail, le plus primitif, décrit dans votre tutoriel? Voici les avantages:

• Véritable intégration continue
• Gestion précoce des conflits - juste après avoir écrit et testé le code
• Réponse rapide - "-Hey, Bob, l'interpolation cubique que tu as écrite donne une sortie amusante, peux-tu la regarder pendant que je suis en train de déjeuner?"
• Aucune fusion ne s’engage - effacez la chronologie comme si un développeur écrivait everithyng

Maintenant, concernant les conflits de fusion compliqués. Je ne comprends pas comment on pourrait expérimenter des fusions fréquentes et compliquées. La complication découle du fait que l’on n’a pas rebasé / piqué au hasard pendant une longue période et qu’on a travaillé sur cette seule caractéristique pendant un mois.

Personnellement, je préférerais m'occuper de conflits de fusion fréquents et faciles (plutôt que de rebases) plutôt que de rares, d'horreur de fusion englobante.

Les fusions et les rebases doivent provoquer exactement les mêmes conflits, pour les conflits inhérents qu'un humain doit résoudre (c'est-à-dire que deux développeurs changent la même ligne de code). Pour les autres conflits, les fusions ont tendance à être plus propres, car vous ne modifiez pas le SHA-1 des commits dans tous les sens. Je ne sais pas comment vous parvenez à entrer dans un état où les fusions causent plus de conflits que de rebaisonnements, mais cela indique certainement que le flux de travail de certaines personnes est perturbé et qu'elles ont probablement besoin de plus de formation sur le fonctionnement de git. Suppriment-ils les commits de fusion d’autres personnes lorsqu’elles effectuent leurs rebases locales, ou quelque chose du genre?

L’avantage et l’inconvénient de la méthode pull-rebase est qu’elle ressemble beaucoup aux workflows centralisés auxquels beaucoup de gens sont habitués. Vous n'avez pas besoin de comprendre les branches pour pouvoir les utiliser.

Quoi qu'il en soit, il est parfaitement possible de créer un flux de travail de branche fonctionnelle uniquement localement, si vous ne pouvez pas y faire adhérer d'autres personnes.

Le projet sur lequel je travaille a ce type de problème de temps en temps et semble résulter de plusieurs facteurs:

• Nous utilisons Visual Studio et des fichiers tels que Visual Studio .sln ne sont que des documents XML (qui ne répondent pas bien aux fusions textuelles) remplis de guides (que Git ne peut pas comprendre mieux que le reste d'entre nous) et peuvent facilement être utilisés. mal fusionné et entraîne la perte de fichiers.
• Certaines personnes travaillent sur des zones similaires du code, de sorte que les modifications apportées soient imbriquées les unes à côté des autres dans les classes. Bien que inévitable dans cette situation, ce type de configuration sera un travail très difficile pour tout système de contrôle de source. Même si vous avez une excellente communication dans votre équipe, parfois, les gens ne réalisent pas qu'ils se heurtent au code de l'autre et que des conflits surgissent.

Je suis intéressé par le potentiel de Semantic Merge pour résoudre certains de ces problèmes, mais ce n'est évidemment utile que si vous travaillez dans une langue qu'il peut analyser et que je n'ai pas encore rencontré de défi significatif. Je ne l’utilise pas, je ne peux donc pas garantir son efficacité.

À moins que les développeurs ne modifient les validations historiques (au lieu des fusions pures), les conflits dans un modèle git de type de flux de travaux d'entité sont le signe d'une affectation de base de code étroitement liée (/ brandnew codebase) ou de chevauchement.

Vous avez une branche principale (principale) et tout le monde travaille dans ses branches principales.

Travailler dans les branches de fonctionnalités peut prendre de quelques heures à quelques mois.

De temps en temps, quelqu'un va inverser la fusion de son jeu de modifications dans la branche principale. Votre chef d'équipe doit s'assurer qu'une seule personne effectue une fusion inversée à la fois. Une fois que cela est fait, vous devez transférer la fusion de la branche principale vers votre branche. Une fois que tout le monde a fusionné, une autre personne peut être autorisée à inverser la fusion dans la branche principale. Sinon, trop de modifications seront fusionnées de manière inverse et vous aurez des tonnes de conflits de fusion lors de votre fusion en aval.

Juste pour clarifier la terminologie, par «fusion inverse», je veux dire une fusion de branche fonctionnelle en une branche principale, et par «fusion avancée», je veux dire une fusion de branche principale en une branche fonctionnelle. D'après ce que j'ai vécu auparavant, vous constaterez probablement davantage de conflits de fusion lors de la fusion inverse, par opposition à la fusion en aval.

Deux choses qui peuvent aider: Premièrement, évitez les outils qui apportent des modifications par eux-mêmes. Deux développeurs utilisant des paramètres d’onglet différents sont une recette pour un désastre. Deuxièmement, apportez des modifications à différents endroits. Vous rencontrez un problème, par exemple, si trois développeurs ajoutent du code à la fin du même fichier, ce qui est bien mieux s'ils ajoutent du code à des endroits différents.