Quand deux modifications se croisent
Sur un projet partagé à plusieurs, ou ouvert sur plusieurs de tes appareils. Aucun réglage à activer.
Deux personnes modifient les mêmes lignes du même fichier : c’est ce qu’on appelle un conflit. Dans VibeStarter, tu n’as pas à le résoudre à la main. Un agent IA s’en charge sur l’ordinateur qui rassemble le travail de l’équipe, et les autres ne voient jamais rien.
Le même conflit arrive sans équipe, entre deux appareils de ton compte qui ont modifié le même fichier. C’est pourquoi les messages parlent de « Conflit de versions ».
Le déroulé d’un conflit
Section intitulée « Le déroulé d’un conflit »Pourquoi tu ne vois jamais de conflit
Section intitulée « Pourquoi tu ne vois jamais de conflit »Chacun enregistre sur sa propre ligne de travail. Ces lignes ne peuvent pas se contredire entre elles : le croisement n’a lieu qu’au moment où quelqu’un les rassemble.
Ce rassemblement est fait par un seul ordinateur à la fois : celui du premier membre connecté, propriétaire ou éditeur. Il garde ce rôle tant qu’il est connecté, même s’il n’a rien à rassembler. Un autre prend le relais s’il se déconnecte, s’il laisse du travail en attente sans avancer pendant 30 minutes, ou s’il ne peut pas rassembler : son propre code ne compile pas, ou un conflit attend et il n’a pas d’agent. C’est là, et nulle part ailleurs, que le conflit est traité. Tous les autres se contentent de recevoir la version de l’équipe une fois qu’elle est propre.
Pendant ce temps, la pastille de synchronisation affiche « Résolution d’un conflit par l’agent… » chez l’intégrateur, et les autres membres peuvent lire « X intègre les changements ».
Le contrôle qui protège la version de l’équipe
Section intitulée « Le contrôle qui protège la version de l’équipe »Une fusion n’est acceptée que si deux conditions sont remplies : elle doit être enregistrée, et le projet doit compiler. Si le résultat ne compile pas, la fusion est annulée et renvoyée à l’agent.
Le même circuit traite les fusions qui n’ont aucun conflit de texte mais dont le résultat ne compile plus — le cas typique où deux personnes ont renommé et utilisé la même chose chacune de son côté.
Conséquence : la version de l’équipe peut être en retard, jamais cassée.
Le seul cas où tu dois agir
Section intitulée « Le seul cas où tu dois agir »Si aucun agent n’est disponible dans le projet, personne ne peut fusionner. La pastille affiche alors, chez les membres concernés :
« Conflit à résoudre — lance un agent »
Il suffit qu’un des deux lance un agent dans le projet. Son ordinateur prend le relais du rassemblement, l’agent est saisi automatiquement, fusionne, puis retourne à ce qu’il faisait. Un agent que tu viens d’ouvrir et à qui tu n’as encore rien demandé convient.
Si aucun agent ne prend le conflit dans la minute, l’application remet tes fichiers comme ils étaient avant. Aucune marque de conflit ne reste dans ton code, et l’enregistrement sur ton ordinateur continue. La sauvegarde en ligne, elle, attend qu’un agent règle le conflit. Rien n’est perdu.
L’application ne te laisse pas passer à côté :
- Au bout d’environ une minute sans agent, une notification reste affichée en bas à droite : « Conflit de versions : lance un agent ». Elle explique : « deux versions d’un même fichier ne s’accordent pas, entre deux de tes appareils ou avec un coéquipier. La sauvegarde en ligne est en pause. » Son bouton Voir le projet te ramène sur les agents du projet. L’application ne lance pas d’agent à ta place.
- Si le conflit est toujours ouvert après dix minutes, qu’un agent s’en occupe ou non, elle te le redit toutes les dix minutes : « Conflit de versions depuis 10 min » — « la sauvegarde en ligne est toujours en pause. Regarde où en est l’agent, ou lances-en un autre. »
- La pastille de synchronisation passe au rouge, et l’onglet du projet affiche « Conflit de versions en attente ».
Tant que le conflit attend, le reste de ton travail ne passe pas non plus chez le coéquipier avec qui tu es en conflit, et tu ne reçois pas le sien : ton travail est intégré en un seul bloc. Tout repart dès que l’agent a fusionné.
Un agent occupé n’est jamais interrompu pour ça : l’application choisit un agent inactif. Voir Lancer et piloter tes agents.
Quand ton travail attend chez quelqu’un d’autre
Section intitulée « Quand ton travail attend chez quelqu’un d’autre »Si tu n’es pas l’ordinateur qui rassemble le travail, ton code est sauvegardé de ton côté, mais il n’est dans la version de l’équipe qu’une fois intégré. Quand cette attente dépasse quelques minutes, le panneau de synchronisation ne dit plus « Ton code est sauvegardé et synchronisé » : il affiche « Ton travail attend d’être intégré depuis 5 min », avec ce qu’il sait de la raison.
| Précision affichée | Ce que ça veut dire | Quoi faire |
|---|---|---|
| « l’app de X, qui rassemble le travail de tous, semble bloquée. Préviens-le. » | L’ordinateur de X n’avance plus, souvent un conflit en attente | Demande à X de regarder sa synchronisation |
| « X, qui rassemble le travail de tous, n’a pas le projet ouvert. » | X a fermé le projet ou l’application | Attends : un autre ordinateur prend le relais |
| « C’est l’app de X qui rassemble le travail de tous. » | X travaille, ton travail n’est pas encore passé | Si ça dure, vois avec X |
| « Nouvel essai automatique. » | L’application ne sait pas quel ordinateur rassemble le travail | Rien, elle réessaie seule |
Rien n’est perdu pendant ce temps : ton travail reste enregistré chez toi et en ligne.
Deux autres blocages qui ressemblent à un conflit
Section intitulée « Deux autres blocages qui ressemblent à un conflit »| Message affiché | Ce que ça veut dire | Quoi faire |
|---|---|---|
| « Publication bloquée : marqueurs de conflit dans … — corrige-les puis republie. » | Des marques de conflit ont été enregistrées dans le code | Corrige les fichiers nommés, puis Republier |
| « Publication en attente : le code ne compile pas — demande à un agent de corriger l’erreur, la publication repartira toute seule. » | La version de l’équipe n’avance que si le code compile. Un agent de code tourne dans le projet | Demande à l’agent de corriger |
| « Publication en attente : le code ne compile pas — lance un agent pour corriger l’erreur, ou corrige le fichier toi-même. La publication repartira toute seule. » | Le même blocage, sans agent de code lancé dans le projet | Lance un agent, ou corrige le fichier toi-même |
Ce blocage vaut pour chaque membre, qu’il rassemble le travail de l’équipe ou non : du code qui ne compile pas reste sur ton ordinateur. Il est sauvegardé chez toi, mais il n’est pas envoyé à tes coéquipiers, et leurs agents ne sont pas dérangés pour le corriger. Pendant ce temps, tes coéquipiers continuent d’échanger entre eux ; toi, tu reçois leur travail une fois ton code réparé.
La ligne « Publication en attente » suit la compilation en direct : elle disparaît dès que le code compile de nouveau, et la publication repart aussitôt. Quand une erreur de compilation dure, l’app enregistre une version et lance une synchronisation sans attendre le cycle suivant : la ligne s’affiche même si le projet est au repos.
Deux avertissements après une intégration
Section intitulée « Deux avertissements après une intégration »Ces deux notifications restent affichées jusqu’à ce que tu les fermes.
| Message affiché | Ce que ça veut dire | Quoi faire |
|---|---|---|
| « Le travail d’un coéquipier n’a pas pu être intégré » | Sur l’ordinateur qui rassemble : le travail d’un coéquipier reste sauvegardé de son côté, mais il n’est pas dans la version de l’équipe | Rien : l’intégration est retentée à sa prochaine modification. C’est aussi ce qui s’affiche quand son travail ne compile pas |
| « N fichier(s) retiré(s) de ton dossier » | Tu avais modifié ces fichiers, et la version qui vient d’être synchronisée ne les contient plus. Ils sont sortis du dossier, pas de l’historique | Ouvre Versions et restaure la version qui les contenait pour les reprendre |
- Deux personnes ne peuvent pas piloter Roblox Studio en même temps sur le même projet. L’application prévient : « Deux personnes synchronisent ce projet », nomme qui pilote quelles places, et demande qu’une seule personne les pilote toutes. Voir La synchronisation, expliquée.
- Travailler à deux sur la même tâche ne marche pas. Un conflit de code se fusionne ; deux visions différentes de la même fonctionnalité, non. Répartissez les sujets.
- Le code écrit en dehors de VibeStarter sera écrasé. Un associé qui modifie les fichiers du projet avec un autre outil ne participe pas à ce circuit.