Studio : copies de travail

Un projet société est en lecture seule. Pour le modifier, on en prend une copie de travail dans le Studio. Le Studio (/studio) rassemble toutes vos copies de travail : vos branches personnelles, éditables.

Le cycle complet reprend les gestes de git :

Projet société (origine)
   │  checkout  ("Travailler dessus")
   ▼
Copie de travail (Studio)  ── éditer ── commit ── commit ──▶
   │  push
   ▼
Pull request  ── revue ── merge ──▶  Projet société (nouvelle version)

Checkout : partir de l'origine

Depuis la liste des projets, cliquez sur Travailler dessus (ou Checkout dans la barre d'actions). Fluhoms crée une copie de travail rattachée au projet d'origine et vous amène dans le Studio.

Le checkout n'est pas un fork : la copie mémorise son origine (origin_project_uuid). C'est ce lien qui permet ensuite de pousser vos changements vers le bon projet société et de récupérer (pull) ses évolutions.

Une copie de travail est privée par défaut : vous seul y accédez, tant que vous ne la partagez pas.

Rejoindre une branche ouverte par quelqu'un d'autre

Un checkout part du projet d'origine et ouvre une branche neuve. Pour travailler sur la branche d'un collègue, il faut au contraire la rejoindre.

Depuis l'onglet Code, choisissez sa branche dans le sélecteur et cliquez sur Rejoindre. Fluhoms crée une copie de travail à vous, rattachée à sa branche, et y matérialise ce que cette branche a publié — son dernier commit.

Ce que vous récupérez, et ce que vous ne récupérez pas

Vous récupérez les commits, pas l'arbre de travail de votre collègue. Ce qu'il a modifié sans commiter reste chez lui : c'est exactement ce que fait git checkout d'une branche distante, et c'est la seule chose qu'on ait à lire chez quelqu'un d'autre.

Plusieurs personnes peuvent ainsi suivre la même branche, chacune avec sa copie privée. Le droit nécessaire est branch:join sur le dépôt : il est distinct du droit de développer, pour qu'une équipe puisse autoriser l'un sans l'autre.

Une branche qui n'a encore rien publié ne peut pas être rejointe — il n'y aurait rien à récupérer.

Récupérer le travail d'un coéquipier

Une fois sur la branche, le bouton Synchroniser ramène chez vous ce que les autres y ont commité. Il est distinct du Pull, qui tire du projet d'origine : ici la source est la branche elle-même.

Les écarts se résolvent comme n'importe quelle fusion — trois branches, conflits remontés, résolution dans l'éditeur. Ce n'est pas un cas particulier : deux contenus qui ont un ancêtre commun se fusionnent de la même façon, d'où qu'ils viennent.

Commiter, c'est publier sur la branche

Fluhoms n'a pas de dépôt local : votre copie de travail est votre espace privé, et un commit place aussitôt son contenu dans l'historique de la branche. Vos coéquipiers le récupèrent en se synchronisant. Ce que vous n'avez pas commité reste chez vous.

Trois niveaux, à ne pas confondre

	Quoi	À qui
Dépôt	le projet société : droits, environnements, chaînes CI/CD, pull requests	tout le monde
Branche	l'historique des commits et le point où elle en est	partagée
Copie de travail	votre espace : flux, connexions, variables en cours d'édition	vous

Les environnements et les chaînes CI/CD appartiennent au dépôt : vous les voyez depuis votre copie, et en créer un depuis celle-ci le crée pour toute l'équipe. Un environnement n'est pas du code — c'est l'endroit où le code tourne, et il ne se duplique pas avec une branche.

Éditer dans le Studio

Dans une copie de travail, tous les onglets d'édition sont disponibles : Pipelines, Workflows, Connexions, Variables. Vous créez et modifiez librement : c'est votre bac à sable.

L'édition d'un pipeline se fait dans l'éditeur visuel (voir Créer un pipeline). Chaque enregistrement crée une autosave : une version de travail non encore commitée.

Commit : figer une version

L'onglet Versions applique le modèle « tout est git ». Il compare votre working tree (l'état édité) au dernier commit et liste les composants modifiés.

Chaque composant modifié (M), non suivi (U) ou supprimé (D) peut être mis en scène (staging) avant le commit.

Le flux :

1. Sélectionnez les composants à inclure (les modifiés sont pré-cochés ; un non-suivi doit être coché explicitement), ou Tout stager.
2. Choisissez l'intention semver (Patch / Mineur / Majeur) par composant.
3. Écrivez un message de commit (obligatoire) puis Commit.

Le commit devient le nouveau HEAD de votre copie. Les versions des sous-pipelines de workflows sont épinglées automatiquement.

Push : proposer les changements à l'origine

Quand votre copie est en avance sur l'origine, la barre de branche propose Ouvrir une PR. Le push crée, sous le capot, une release de vos commits et ouvre une pull request vers le projet société d'origine.

• Si l'origine exige une revue, la PR arrive dans son onglet À valider et attend une approbation avant d'être mergée.
• Sinon, elle peut être mergée directement.

Repousser sur une PR déjà ouverte

Comme sur GitHub, une pull request est identifiée par un couple — votre branche et le projet visé — et non par son contenu. Pousser de nouveaux commits alors qu'une PR est ouverte ne crée pas une seconde demande : la PR avance. Elle garde son lien, son fil et son auteur ; seule sa tête bouge, et la liste de ses commits s'allonge.

Les approbations déjà données tombent

Le quorum atteint déclenche la fusion immédiatement. Conserver une approbation donnée sur un contenu qui a changé depuis laisserait le dernier approbateur fusionner du code que les précédents n'ont jamais vu. Les votes ne sont pas perdus pour autant : ils passent à l'historique de revue de la PR, avec le nom de qui avait approuvé.

Pousser sans rien avoir commité de neuf ne coûte rien : la PR est déjà à jour, et ses votes sont conservés.

Un push refusé — droit manquant, par exemple — ne laisse aucun commit derrière lui : la gouvernance répond avant que quoi que ce soit ne soit figé.

Ce que la fusion écrit, et ce qu'elle n'écrit pas

Une pull request emporte tous les composants de votre branche, pas seulement ceux que vous avez touchés. À la fusion, seuls les composants réellement modifiés reçoivent une nouvelle version dans le projet d'origine.

Les autres sont laissés tels quels. C'est ce qui rend l'historique du projet lisible : après une PR qui modifie un flux sur vingt, l'origine montre une version neuve, pas vingt dont dix-neuf identiques à la précédente.

Pull : récupérer les évolutions de l'origine

Si l'origine a avancé pendant que vous travailliez, vous devez d'abord vous mettre à jour : la barre de branche affiche En retard et propose Pull. Tant qu'un pull est requis, l'ouverture de PR est masquée.

La résolution des écarts (y compris les conflits) se fait visuellement dans l'éditeur ; c'est le sujet du guide dédié : Pull et résolution de merge.

En résumé

• On checkout une origine → copie de travail privée dans le Studio.
• On rejoint la branche d'un collègue → copie privée sur sa branche.
• On synchronise pour récupérer ce que l'équipe a commité sur la branche.
• On édite puis on commit (working tree → versions figées).
• On push → release + pull request vers l'origine ; un push suivant fait avancer la PR ouverte au lieu d'en créer une seconde.
• On pull pour rester à jour, en résolvant les écarts dans l'éditeur.