Guide de collaboration

jinflow utilise git pour la collaboration. Chaque AFS tenant est un dépôt git dès sa création. Les équipes partagent leur travail via GitHub (ou tout remote git).

Deux façons de commencer

1. Nouveau tenant (premier analyste)

Créer un tenant depuis un domain pack, connecter à GitHub, pousser :

# Create from pack
jinflow init --pack millesime --tenant szo

# Connect to GitHub (create the repo on GitHub first)
jinflow afs remote https://github.com/org/afs-millesime-domaine_zufferey.git

# Push initial state
jinflow afs push -m "initial setup"

2. Rejoindre un tenant existant (deuxième analyste)

Cloner l’AFS depuis GitHub — pas de pack nécessaire :

# Clone from GitHub
jinflow init --clone https://github.com/org/afs-millesime-domaine_zufferey.git

# Sync data and build
jinflow make --tenant millesime.domaine_zufferey --sync --clean

Cela crée la structure complète du tenant (raw/, build/, store/) autour de l’AFS cloné. Le pack n’est pas nécessaire — l’AFS EST le framework analytique.

Workflow quotidien

# Start of day: pull team changes
jinflow afs pull

# Work: edit signals, theses, notes
# Build and explore
jinflow make
jinflow explore

# End of day: push your changes
jinflow afs push -m "added io_coefficient signal"

Commandes AFS

jinflow afs remote                    # show current remote
jinflow afs remote <url>              # set remote (add or update)
jinflow afs status                    # show branch, tags, changes
jinflow afs log                       # build logbook (git log)
jinflow afs log -n 10                 # last 10 entries
jinflow afs pull                      # pull from remote (fast-forward only)
jinflow afs push                      # commit all changes + push
jinflow afs push -m "message"         # with custom commit message

Ce qui est versionné

L’AFS (afs/) est le dépôt git. Il contient :

Contenu	Versionné	Notes
Signals, Theses, Verdicts	Oui	Les instruments analytiques
SMEbits, BitBundles	Oui	Connaissances expertes
Notebooks	Oui	Notes d’investigation
Entities, lineage, Contracts	Oui	Définitions de schémas
Macros dbt, seeds, tests	Oui	Logique de transformation de données
Models (bronze, silver, gold)	Oui	Modèles SQL source
jinflow.yml	Oui	Configuration du pack
tenant/ (config, logo, seeds)	Oui	Contenu spécifique au tenant

Ce qui N’EST PAS dans git (vit à côté de l’AFS) :

Contenu	Emplacement	Notes
CSV bruts	raw/	Données source immuables depuis la DLZ
Artefacts de build	build/	SQL compilé, CSV enrichis (régénérables)
KLS + SIS	store/	Bases de données construites (régénérables via make)

Auto-commits

jinflow make auto-commite un one-liner structuré après chaque build :

jinflow make: ok | clean | 34/0/1 | v0.7.9 | darwin | mig | millesime.domaine_zufferey | 12.3s

jinflow afs update --do-it auto-commite après la synchronisation du contenu du pack.

Ces auto-commits créent un logbook de build visible via jinflow afs log.

Packs

Les domain packs sont des dépôts git indépendants (par ex. jinflow-pack-millesime). Ils sont clonés manuellement :

git clone https://github.com/jinflow-io/jinflow-pack-millesime.git

Configurez la racine des packs pour que jinflow puisse les trouver :

jinflow us --pack-root ~/jinflow-packs

Les changements de pack s’intègrent dans l’AFS tenant via jinflow afs update --do-it.

Résolution de conflits

jinflow afs update utilise une fusion three-way (manifeste SHA-256) :

• Seul le pack a changé → mise à jour sûre (appliquée automatiquement)
• Seul le tenant a changé → préservé (votre personnalisation gagne)
• Les deux ont changé → conflit (PAS écrasé, signalé pour résolution manuelle)
• Mode forcé → --force fait gagner le pack sur les conflits

jinflow afs pull utilise le fast-forward uniquement. Si local et remote divergent, il vous indique de résoudre manuellement avec git pull --rebase.