Vous ne pouvez pas fusionner les octets de deux VI modifiés, donc un conflit de fusion LabVIEW a deux issues. Choisir un côté avec git checkout --ours ou --theirs, puis refaire à la main dans LabVIEW la modification de l'autre côté. Ou lancer LVMerge, si vous avez une licence Professional et que les deux branches se chargent sur votre machine. Dans les deux cas vous rouvrirez le VI, parce qu'il n'y a pas de texte à résoudre.
À quoi ressemble le conflit
Git vous dit d'emblée qu'il n'essaiera pas. La ligne d'avertissement est celle à lire.
$ git merge widen-3v3-limitwarning: Cannot merge binary files: FCT/Power Rails.vi (HEAD vs. widen-3v3-limit)Auto-merging FCT/Power Rails.viCONFLICT (content): Merge conflict in FCT/Power Rails.viAutomatic merge failed; fix conflicts and then commit the result.$ git statusOn branch mainYou have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge)Unmerged paths: (use "git add <file>..." to mark resolution) both modified: FCT/Power Rails.viLe fichier sur le disque à cet instant est l'une des deux versions, pas un mélange, et Git ne dira pas laquelle sans qu'on le lui demande. Ne l'ouvrez pas encore dans LabVIEW. Décidez d'abord.
La décision
| Situation | Faites ceci |
|---|---|
| La modification d'un côté est petite (une constante, une limite, un fil) | Gardez l'autre côté, refaites la petite modification à la main |
| Les deux côtés ont fait de vrais changements de diagramme, vous avez Professional, les deux branches se chargent | LVMerge |
| Le VI est un membre de classe ou un typedef | Manuel, toujours. LVMerge et le renommage qu'il exige ne tiennent pas sur les classes |
| Aucune machine de l'équipe n'a Professional | Manuel, toujours |
| Vous êtes dans un rebase, pas une fusion | Mêmes étapes, mais --ours et --theirs échangent leur sens (voir ci-dessous) |
| Vous ne savez pas ce que l'autre côté a changé | Demandez, ou lancez git log -1 --format=%B <branch> -- "FCT/Power Rails.vi" et lisez le message de commit. Ce message est tout l'historique dont vous disposez |
Cette dernière ligne est le vrai coût. Sur un fichier texte, vous liriez le diff. Sur un VI, le message de commit est le diff, et c'est pourquoi « limites corrigées » comme message vous coûte un après-midi plus tard. Pourquoi le contrôle de version LabVIEW est si pénible donne le mécanisme complet.
La voie manuelle
Elle fonctionne avec n'importe quelle licence et sur n'importe quelle machine capable d'ouvrir le VI.
# Garde un côté du VI, puis refait à la main dans LabVIEW la modification de l'autre côté.git checkout --ours -- "FCT/Power Rails.vi"# ou, pour garder la version de la branche entrante à la place :# git checkout --theirs -- "FCT/Power Rails.vi"# Ouvrez le VI dans LabVIEW, refaites la modification de l'autre côté, enregistrez. Puis :git add "FCT/Power Rails.vi"git commit -m "Merge widen-3v3-limit: redo the 3.15 V floor in Power Rails.vi by hand"Étape par étape :
- Choisissez le côté avec la plus grosse modification et extrayez-le. Dans une fusion,
--oursest la branche sur laquelle vous êtes et--theirsla branche que vous fusionnez. Dans un rebase ils s'échangent :--oursest l'amont sur lequel vous rebasez et--theirsvotre propre commit en cours de rejeu. - Ouvrez le VI dans LabVIEW et refaites la plus petite modification. Servez-vous du message de commit de l'autre branche, ou demandez à l'auteur.
- Enregistrez. Si les deux branches ont été construites sur la même version et la même architecture de LabVIEW, vous en avez fini avec LabVIEW. Si la fusion a traversé un changement de version ou d'architecture, lancez la compilation de masse du projet maintenant, et seulement maintenant. Une compilation de masse réécrit chaque VI qu'elle touche, donc la lancer pour un conflit sur un seul VI ajoute du bruit au commit sans raison.
git addle VI et validez. Mettez ce que vous avez refait dans le message, avec la valeur. C'est le seul endroit où cela sera jamais écrit.
Exécutez le VI une fois avant de pousser. Il n'y a pas de diff à relire, donc le test est la revue.
La voie LVMerge
LVMerge fait une vraie fusion à trois voies : Base (l'ancêtre commun), Theirs, Yours, vers un VI fusionné que vous acceptez différence par différence. Il faut la configuration mergetool de LVCompare et LVMerge : ce qu'ils ne peuvent pas faire, une licence Professional, et chaque SubVI et classe des deux branches résoluble sur cette machine.
# Fusion à trois voies avec LVMerge. Nécessite Professional et la configuration mergetool lvmerge.git config mergetool.keepBackup falsegit mergetool --tool=lvmerge -- "FCT/Power Rails.vi"# LVMerge ouvre Base, Theirs et Yours. Acceptez ou rejetez chaque différence, puis enregistrez.git add "FCT/Power Rails.vi"git commitÉtape par étape :
- Lancez
git mergetoolsur ce seul fichier. Git écrit les trois entrées dans des chemins absolus temporaires et appelle LVMerge dans l'ordre Base, Theirs, Yours, Merged. - Parcourez la liste des différences. Chaque entrée est un changement de face-avant, de diagramme ou d'attribut venant d'un côté.
- Avant d'enregistrer, lisez une fois le diagramme fusionné. LVMerge peut dupliquer un nœud qu'une branche a supprimé puis rajouté. Retirez le doublon.
- Enregistrez,
git add, validez.keepBackup falseempêche Git de laisser une copie.origdu VI à côté du vrai, que LabVIEW trouverait sinon au chargement suivant.
Si LVMerge se bloque sur une boîte de dialogue de dépendance, abandonnez, et prenez la voie manuelle sur la machine de développement qui a le projet complet.
Comment éviter que cela se reproduise
Le conflit est le symptôme de deux personnes qui ont besoin du même fichier binaire en même temps. Quatre habitudes réduisent la fréquence, par ordre de coût.
Une seule personne par VI à la fois. Annoncez dans quels VI vous êtes avant de commencer, dans le canal ou dans un LOCKS.md à la racine du dépôt, et personne d'autre ne les ouvre avant que vous ayez poussé. C'est une convention, pas un mécanisme, et cela tient dans une petite équipe.
Des VI plus petits. Un VI de 40 nœuds qui fait tout le test est un fichier dont deux personnes auront besoin. Découpez par phase et la probabilité que deux ingénieurs soient dans le même fichier chute.
Les limites dans un fichier de configuration, pas dans le diagramme. La plupart des conflits sur les VI de test viennent de deux personnes qui changent deux constantes différentes dans un même fichier. Sortez les constantes, et le VI cesse de changer quand une limite change.
; Lu par le VI de test avec les VI Config File. Ce fichier se compare et se fusionne dans Git seul.[rail_3v3]min = 3.15max = 3.4[rail_5v]min = 4.85max = 5.15Le code compilé séparé du fichier source. Le réglage « Separate compiled code from source file » n'empêche pas un vrai conflit à deux modifications, mais il supprime les faux, où un VI apparaît modifié parce qu'un appelé a changé. Le code compilé séparé dans LabVIEW, expliqué couvre le réglage. Avec les notes de passation de documenter un poste de test pour la passation, c'est ce qui rend la voie manuelle supportable quand l'auteur de l'autre branche est parti.
Le contraste
Un poste TofuPilot Framework est du texte : procedure.yaml, phases/*.py, plugs/*.py. Le même conflit, deux branches changeant toutes deux le plancher du 3,3 V, ressemble à ceci.
- name: rail_3v3 unit: V validators: - operator: ">="<<<<<<< HEAD expected_value: 3.15======= expected_value: 3.1>>>>>>> widen-3v3-limit - operator: "<=" expected_value: 3.4Vous lisez les deux valeurs, en gardez une, supprimez les marqueurs, git add, commit. Tous les autres changements des deux branches ont fusionné automatiquement. Ensuite, git blame répond à la question à laquelle le message de commit LabVIEW ne pouvait pas répondre.
$ git blame -L 25,26 procedure.yamla41f9c2e (Priya Raman 2026-09-14 10:22:41 +0200 25) - operator: ">="7d03be51 (Marc Dubois 2026-09-18 16:05:09 +0200 26) expected_value: 3.15Qui a mis le plancher à 3,15, quel jour, dans quel commit. Et une fois ce commit poussé, le poste récupère le déploiement et chaque run qu'il envoie à TofuPilot porte l'identifiant du déploiement, donc les unités testées sous 3,15 sont un filtre sur la liste des runs.
Commencez par un poste
Prenez le poste dont les VI entrent le plus souvent en conflit, ou celui qu'une seule personne peut ouvrir. Reconstruisez-le sous forme de procedure.yaml avec ses phases et ses plugs en Python avec le TofuPilot Framework, gardez les mêmes limites, et faites-le tourner en parallèle de la version LabVIEW sur les mêmes unités pendant deux semaines.
# Installe le CLI, puis lance le poste en local (sans compte) ou avec upload.curl -fsSL https://www.tofupilot.app/install | shtofupilot run ./procedure.yamltofupilot run ./procedure.yaml --uploadLa reconstruction est dans comment migrer de LabVIEW vers Python pour les tests de fabrication avec TofuPilot, et le framework est sur tofupilot.com/products/framework. L'offre Lab est gratuite, et tofupilot run fonctionne sans compte.
