pull-changes-resolve-conflicts

À propos de pull-changes-resolve-conflicts

Un flux de travail guidé pour intégrer une branche dans une autre (généralement en tirant les modifications de la branche principale vers une branche fonctionnelle) dans des projets impliquant plusieurs contributeurs, sans jeter silencieusement du travail intentionnel. Il s’applique à tout flux de travail d’équipe basé sur Git, les applications Flows/React étant un cas fréquent où les conflits ont tendance à apparaître dans les structures d’application, la navigation principale, les modules de routes, ainsi que dans les répertoires partagés lib/ ou hooks/. Le principe fondamental est que la résolution des conflits ne doit jamais supposer a priori que « la branche principale l’emporte » ou « notre version l’emporte », et que les compromis doivent être rendus visibles à l’utilisateur avant toute modification des marqueurs de conflit.

Le flux de travail se déroule en plusieurs étapes : récupération et intégration (on préfère d’abord git fetch suivi de git merge origin/main, sauf si une rebase a été demandée), puis indication explicite de chaque fichier non fusionné accompagnée d’une brève explication sur ce qui a provoqué la divergence, suivie d’une analyse à l’aide de l’historique des discussions, des signaux du dépôt (comme un PRD.md ou des commits récents), ainsi que des parties concernées par le conflit via git show :2:path (notre version) et git show :3:path (leur version). Les conflits sont classés en orthogonaux (peuvent être combinés sans problème), en chevauchants (il faut choisir ou fusionner manuellement), ou présentant un risque de corruption (blocs dupliqués dus à des fusions incorrectes). Les résultats sont ensuite présentés sous forme de recommandations hiérarchisées et de questions précises, classées de P0 (changements structurels ou liés au produit tels que suppression de routes, suppression de fonctionnalités, modification des données ou des contrats API) à P3 (ajustements de présentation comme l’espacement ou les noms de classes).

Des règles strictes interdisent toute résolution silencieuse : les marqueurs de conflit ne sont pas supprimés et git add n’est pas exécuté tant que l’utilisateur n’a pas approuvé le plan ou n’a pas explicitement choisi de suivre les recommandations. L’outil s’arrête aux conflits sans forcer l’intégration de fichiers volumineux, et permet d’annuler l’opération via git merge --abort ou git rebase --abort. Il liste également des anti-modèles à éviter, tels que le choix systématique de --ours ou --theirs dans tout le dépôt, ou la dissimulation d’une liste de conflits au sein d’un long bloc de code sans résumé succinct. Des extraits de commandes optionnels et un modèle de message de fusion se trouvent dans le fichier reference.md accompagnant l’outil.

FAQ

Quand dois-je utiliser cet outil ?

Chaque fois que vous intégrez une autre branche (généralement la branche principale) dans votre branche fonctionnelle actuelle, ou lorsque git status indique des chemins non fusionnés après une fusion ou une rebase. Il s’applique à tout flux de travail d’équipe basé sur Git, les applications Flows/React étant un cas courant.

Va-t-il résoudre automatiquement les conflits sans me demander mon avis ?

Non. Une règle stricte interdit toute résolution silencieuse : il ne supprimera pas les marqueurs de conflit ni n’exécutera git add tant que vous n’avez pas approuvé le plan ou indiqué explicitement de suivre ses recommandations. Il s’arrête aux conflits et les signale en premier.

Comment décide-t-il quels conflits aborder en premier ?

Les conflits sont classés selon leur impact, de P0 (changements structurels ou liés au produit tels que suppression de routes, suppression de fonctionnalités, ou modification des données et des contrats API) jusqu’à P3 (ajustements de présentation comme l’espacement, les noms de classes ou le texte affiché).

Quelles informations utilise-t-il pour analyser un conflit avant de le modifier ?

Il utilise l’historique des discussions concernant les modifications prévues pour la branche, des signaux du dépôt tels qu’un PRD.md ou des commits récents ainsi que l’auteur des fichiers, et les parties concernées par le conflit via git show :2:path pour notre version et git show :3:path pour la leur.

Que se passe-t-il si je veux simplement annuler la fusion ?

L’outil permet d’exécuter git merge --abort ou git rebase --abort selon le cas, et indique que l’état d’intégration en cours sera perdu suite à cette opération.

Tous les fichiers

2 fichiersreference.md0,7 KBAfficherSKILL.md5,5 KBAfficher