En résumé
N’importe quelle entité — projet, pipeline ETL, alignement de concepts, espace de travail — se lie à un dépôt git pour garder un historique et travailler à plusieurs. Le mécanisme est identique pour les dix types. La décision qui compte : versionner un espace de travail d’un bloc, ou donner à chaque élément son propre dépôt et son propre rythme — l’espace de travail ne gardant alors qu’un pointeur vers chacun.
Pourquoi git
Un travail sur données de santé dure des mois et se modifie constamment : on affine un critère d’inclusion, on corrige un script, on refait un graphique. Sans historique, deux questions restent sans réponse — « qu’est-ce qui a changé depuis l’analyse de mars ? » et « qui a modifié ce critère, et pourquoi ? »
Git répond aux deux. Linkr l’utilise sans vous demander de le connaître : les commandes sont des boutons, et les fichiers versionnés sont vos entités, pas du code.
Ce que git apporte concrètement ici
Un historique daté et signé de chaque modification, la possibilité de revenir en arrière, et le travail à plusieurs sur le même contenu sans s’écraser mutuellement. Si ces notions sont nouvelles, voir Versioning et collaboration.
Le contenu poussé est exactement celui de l’archive ZIP : la même arborescence de fichiers texte. Ces deux sorties sont décrites dans Import et export ; cette page traite de la seconde.
Lier une entité à un dépôt
Depuis le menu d’une entité — les trois points de sa carte —, Versioning ouvre une fenêtre à deux onglets, Dépôt Git et Export. Pour un projet et pour l’espace de travail, c’est une page, Versioning et export, avec les mêmes onglets.
Tant que rien n’est lié, l’onglet Dépôt Git affiche un formulaire de connexion : l’URL du dépôt, et un jeton d’accès si le dépôt est privé. Linkr vérifie le dépôt avant d’enregistrer et détecte la branche.
Optionnel. Requis uniquement pour un dépôt privé (jeton d'accès personnel). Votre jeton est enregistré pour vous et réutilisé pour tous les dépôts de cet hôte — les autres utilisateurs ne le voient jamais.
Le jeton reste confidentiel
Il est enregistré pour vous, par serveur, et réutilisé pour tous les dépôts de ce serveur. Les autres utilisateurs ne le voient pas, l’interface ne le renvoie jamais, et il ne figure dans aucun export ni dans le dépôt lui-même.
Une fois lié, l’onglet devient le panneau de synchronisation décrit plus bas. L’adresse du dépôt, le jeton et la déconnexion passent dans la fenêtre Paramètres du dépôt, ouverte par le bouton Paramètres de ce panneau : on n’y touche qu’une fois.
Paramètres du dépôt
Le dépôt distant où ce contenu est versionné, et le jeton d'accès utilisé pour l'atteindre.
Reconstruire ce contenu depuis le dépôt.
Ce qui est ici est remplacé par ce que contient le dépôt.
Délier ce dépôt.
Votre contenu local est conservé ; rien n'est supprimé à distance.
- Réinstaller — absent pour l’espace de travail et les plugins, et réservé à qui peut supprimer l’élément — reconstruit le contenu depuis le dépôt : ce qui est ici est supprimé puis réimporté tel que le dépôt le contient. Tout ce qui n’a pas été poussé est perdu — Linkr le redit dans une confirmation. C’est le recours quand une copie locale est abîmée, ou pour reprendre la version du dépôt d’un contenu qui ne sait pas encore récupérer ses modifications.
- Déconnecter délie le dépôt ; votre contenu local est conservé, et rien n’est supprimé à distance.
Synchroniser
Deux onglets organisent le travail courant, sous une ligne commune : la Branche, Paramètres et Actualiser.
Valider et pousser tout ce qui a changé dans ce projet (métadonnées, scripts, tableaux de bord, cohortes, jeux de données et pipeline).
- Mentity.json
- MREADME.md
- Acohorts/ventiles-48h.json
- Mdashboards/mortalite-j28.json
Valider et pousser uniquement les tableaux de bord.
- Mdashboards/mortalite-j28.json
Actions rapides
Une carte Tout synchroniser valide et pousse tout ce qui a changé, avec un message de commit rédigé pour vous. Elle liste avant d’agir ce qui sera poussé. D’autres cartes, selon le contenu, ne poussent qu’une partie — les tableaux de bord, les scripts.
C’est l’usage courant : vous avez travaillé, vous synchronisez, c’est fini.
Détails
La vue fichier par fichier, pour choisir ce qui part. Chaque fichier modifié s’affiche avec une description en clair de ce qu’il contient — « Une définition de cohorte (ses critères d’inclusion/exclusion) » — et son différentiel est consultable.
À utiliser quand une partie seulement du travail est prête à être partagée.
Récupérez avant de pousser
Si le dépôt distant contient des modifications que vous n’avez pas, Linkr refuse de synchroniser et vous le dit : « Le dépôt distant contient des modifications que vous n’avez pas encore — récupérez-les avant de pousser, sinon votre push les écraserait. » C’est ce qui évite d’écraser le travail d’un collègue.
Récupérer le travail des autres
Quand le dépôt a bougé, le panneau change de sens : il n’affiche plus ce que vous pourriez pousser, mais ce qu’il y a à récupérer. Vous choisissez quoi appliquer, et un différentiel est consultable avant de valider. Si les deux côtés ont changé le même élément, c’est à vous de trancher : Garder les miens ou Prendre le leur.
Quelqu'un a poussé : récupérez avant de pousser.
La récupération existe pour les alignements de concepts, les pipelines ETL, les schémas, les bases de données et les paramètres de l’instance.
Pas de récupération pour les projets
Pour un projet — comme pour l’espace de travail, les collections de scripts, les règles de qualité, les catalogues et les plugins —, le panneau affiche : « La récupération (pull) n’est pas encore implémentée pour ce type de contenu. » Vous poussez, mais les modifications faites sur le dépôt ne reviennent pas automatiquement. Pour reprendre la version du dépôt, Paramètres › Réinstaller la reprend en entier — partout sauf pour l’espace de travail et les plugins. Voir Versioning d’un projet.
Un espace de travail, ou chaque élément séparément
C’est la décision structurante, et elle mérite d’être prise en connaissance de cause. Un espace de travail contient des projets, des pipelines ETL, des schémas, des alignements de concepts. Deux arrangements sont possibles — et ils se combinent.
Un dépôt pour tout
L’espace de travail emporte ses éléments en entier.
Un seul dépôt, un seul historique. Simple à mettre en place, et suffisant pour un espace de travail qui vit d’un seul tenant.
Un dépôt par élément
Chaque élément a son dépôt et son cycle.
L’espace de travail ne garde qu’un pointeur vers chacun. C’est l’arrangement recommandé dès que les éléments évoluent à des rythmes différents.
Ce que change le pointeur
Lier un élément à son propre dépôt modifie ce que l’espace de travail emporte le concernant. L’infobulle de l’export le dit : « Seules les métadonnées et le lien Git sont exportés — le contenu complet reste dans le dépôt Git lié. »
Concrètement, l’export de l’espace de travail ne contient plus, pour cet élément, qu’une fiche d’identité et l’adresse de son dépôt. Qui importe l’espace de travail récupère la liste de ses éléments, puis Linkr clone chacun des dépôts liés pour en reconstituer le contenu.
Pourquoi c'est l'arrangement recommandé
Un pipeline ETL et un projet d’analyse n’évoluent pas au même rythme : le premier se stabilise, le second change toutes les semaines. Avec un dépôt unique, chaque modification de l’un encombre l’historique de l’autre, et il devient impossible de dire « donne-moi la version du pipeline utilisée pour l’article ».
Des dépôts séparés donnent à chaque élément son historique, ses versions et sa licence — et permettent de le publier seul, sans emporter le reste de l’espace de travail.
Le mélange est normal
La décision se prend élément par élément, et rien n’impose l’uniformité. Au moment de l’export, Linkr regarde chaque élément : s’il est lié à un dépôt, il écrit un pointeur ; sinon, il écrit son contenu.
| L’élément est… | Dans l’export de l’espace de travail | Dans son propre export |
|---|---|---|
| lié à un dépôt | Métadonnées + adresse du dépôt. | Son contenu complet. |
| non lié | Son contenu complet, imbriqué dans l’arborescence. | Son contenu complet. |
Un espace de travail typique finit donc mixte : le pipeline ETL et le schéma OMOP, mutualisés et publiables, ont chacun leur dépôt ; les projets en cours, propres à l’équipe, voyagent dans l’espace de travail.
L'export d'un élément lié contient tout, lui
Une confusion fréquente : exporter un élément depuis sa propre fenêtre produit toujours son contenu complet, qu’il soit lié ou non. Seuls les exports d’espace de travail le réduisent à un pointeur.
À l'import, un dépôt privé demande un jeton
L’import d’un espace de travail clone les dépôts liés sans présenter d’identifiants. Ceux qui sont privés restent donc vides, et Linkr les liste dans un panneau : vous saisissez un jeton d’accès et chargez chacun d’un bouton Cloner.
Ce qui ne part jamais
Trois choses restent chez vous, quel que soit l’arrangement.
Les données patient
Exclues par défaut, avec le journal de modifications qui les accompagne. Un fichier ne part que si vous le marquez explicitement.
Les mots de passe et jetons
Hôtes, ports, comptes, mots de passe : rien de tout cela ne quitte la machine. Qui récupère le contenu redéclare ses propres connexions.
Les résultats d’exécution
L’effectif d’une cohorte, son attrition : ils dépendent de la base interrogée, pas de la définition. Chaque installation les recalcule.
Le format rend les différentiels lisibles
Les entités étant écrites en fichiers texte, un outil de comparaison affiche exactement ce qui a changé entre deux versions. Un critère d’inclusion ajouté se lit sur une ligne — ce qu’aucun format binaire ne permettrait.
Pour aller plus loin
- Import et export — l’autre sortie, et ce que contient exactement une archive.
- Publier du contenu — de la mise en dépôt à l’entrée de catalogue.
- Versioning d’un projet — ce qu’emporte précisément un projet.
- Versioning et collaboration — les principes, si git vous est étranger.