Fastodata / Onboarding

Module d'onboarding — Git & CI (workflow data)

Contenu pédagogique produit par Bill (QA). Destiné à onboarding.fastodata.com.
Public : tout nouvel arrivant tech. Format : théorie d'abord → exercices → quiz corrigé.
Contexte équipe : conventions de branches/commits/PR, CI sur les projets data (dbt, Terraform, Kestra).
Durée estimée : ~2-3 h.

Objectifs pédagogiques

À la fin, l'apprenant sait :

  1. Manipuler le flux Git quotidien (clone, branch, commit, push, PR).
  2. Respecter les conventions d'équipe (nommage branches, messages de commit).
  3. Résoudre un conflit de merge sans paniquer.
  4. Comprendre rebase vs merge et quand utiliser quoi.
  5. Lire un pipeline CI et comprendre ce qui bloque une PR.

Module 1 — Le flux quotidien

Git suit l'historique du code par commits (instantanés). Le travail se fait sur des branches isolées, fusionnées via Pull Request (PR).

Cycle type :

git checkout main && git pull          # repartir d'un main à jour
git checkout -b feat/ajout-modele      # créer sa branche
# ... modifs ...
git add -p                             # stager par morceaux (relire ce qu'on commite)
git commit -m "feat(dbt): ajoute stg_orders + tests"
git push -u origin feat/ajout-modele   # pousser, puis ouvrir la PR

⚠️ Règle d'or : on ne commite jamais directement sur main. Toujours une branche + PR + revue.

Module 2 — Conventions d'équipe

Module 3 — Conflits & historique

Conflit de merge : deux branches modifient la même zone. Git marque la zone :

<<<<<<< HEAD
ta version
=======
la version de l'autre branche
>>>>>>> main

On édite pour garder le bon résultat, on retire les marqueurs, puis git add + on finalise. Pas de panique : un conflit se résout fichier par fichier.

Annuler proprement :

Module 4 — Rebase vs merge

Module 5 — CI : ce qui garde une PR honnête

Sur les projets data, la PR déclenche une CI (GitHub Actions / GitLab CI) qui automatise les vérifs avant merge :

Une PR rouge (CI en échec) ne se merge pas : on lit les logs du job, on corrige, on re-push (la CI repart). C'est exactement le filet que Bill (QA) recoupe avant un go.

Bonne pratique : faire tourner les checks en local avant de pousser (pre-commit hooks) pour ne pas découvrir l'échec en CI.

Exercices

  1. Tu démarres une correction de bug sur la table orders. Donne le nom de branche + le 1er message de commit (conventions équipe).
  2. git pull te met un conflit sur models/stg_orders.sql. Décris les 3 étapes pour le résoudre.
  3. Tu as poussé un commit qui casse la prod. Quelle commande pour l'annuler sans réécrire l'historique ?
  4. Ta branche a 10 commits de retard sur main. Rebase ou merge pour te remettre à jour, et pourquoi ?
  5. Ta PR est rouge en CI sur l'étape dbt build. Quelle est ta démarche ?

Quiz final corrigé

Q1. Pourquoi ne jamais commiter directement sur main ?
→ Pas de revue ni de CI → risque de casser la base de tous. Branche + PR + checks garantissent qualité et traçabilité.

Q2. Format d'un message de commit conventionnel ?
→ type(scope): description à l'impératif (ex. fix(dbt): corrige le test unique). Types : feat/fix/chore/docs/refacto…

Q3. Que fait git revert vs git reset ?
→ revert crée un commit d'annulation (sûr, garde l'historique, OK sur du poussé). reset déplace HEAD (réécrit l'historique — dangereux en partagé).

Q4. Quand NE PAS rebaser ?
→ Sur une branche partagée déjà tirée par d'autres : le rebase réécrit l'historique et casse leur copie.

Q5. Une PR est rouge en CI. On la merge ?
→ Non. On lit les logs du job en échec, on corrige, on re-push (la CI relance). Merge seulement quand c'est vert.

Pour aller plus loin

→ BigQuery → dbt (data build tool) → Airflow → Kestra