Résoudre les conflits Git en préservant l’intention des branches.
La résolution doit préserver les changements voulus des deux côtés lorsqu’ils sont compatibles. Demandez le comportement métier attendu si la syntaxe seule ne suffit pas.
Adaptez le processus à votre tâche.
Lisez les versions en conflit et le code environnant, puis identifiez l’intention de chaque changement. Combinez les comportements compatibles et demandez une décision si les exigences se contredisent, puis testez l’interaction obtenue.
- Ce que vous fournissez
- Marqueurs de conflit et changements prévus.
- Ce que vous obtenez
- Explication du conflit et proposition de version fusionnée.
Consultez les données et le résultat.
Entrée et sortie illustratives · exemple pédagogique, pas une exécution WebAct en direct
Exemple champ
Resolve this simplified HTML conflict: base button was <button type="button">Save</button>. Branch A changes its label to Save draft. Branch B adds disabled because submission is unavailable.
Exemple complet
<button type="button" disabled>Save draft</button> Both changes are retained: the new label and the unavailable state. Confirm when the application should remove disabled; the merged markup alone does not implement that state transition.
Chargez ces données dans le prompt, puis copiez-le dans WebAct pour essayer la tâche. Votre résultat peut différer de l'illustration.
Décisions et dépannage.
Choisir ours ou theirs résout-il toujours entièrement un conflit ?
Cela peut supprimer un changement valide de l’autre côté. Comparez les intentions avant de choisir ou combiner le contenu.
Pourquoi une fusion syntaxiquement propre casse-t-elle encore la fonctionnalité ?
Le comportement combiné peut entrer en conflit même sans marqueurs. Vérifiez état, gestion des événements et exigences visées par les deux branches.
Essayez avec votre propre source.
Remplacez l'exemple par vos données dans le prompt. Gardez les exigences nécessaires, puis copiez la tâche dans WebAct.
Personnaliser et copier la tâche ↑