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 neuf 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.
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.
Où trouver un jeton d'accès
Sur GitLab : Préférences › Jetons d’accès, avec les droits read_repository et write_repository. Sur GitHub : Settings › Developer settings › Personal access tokens, avec le droit repo. L’application rappelle ces chemins sous le champ.
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 se résume à une ligne : l’adresse du dépôt, une pastille si le dépôt est privé, et de quoi modifier le jeton ou délier.
Synchroniser
Deux onglets organisent le travail courant.
Actions rapides
Un bouton Tout synchroniser valide et pousse tout ce qui a changé, avec un message de commit rédigé pour vous. Il liste avant d’agir ce qui sera poussé.
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
Le panneau de récupération liste ce qui a changé côté dépôt, et vous choisissez quoi appliquer. Un différentiel est consultable avant de valider, ce qui permet de voir qu’une cohorte a gagné un critère avant de l’accepter.
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.