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 :

Manipuler le flux Git quotidien (clone, branch, commit, push, PR).
Respecter les conventions d'équipe (nommage branches, messages de commit).
Résoudre un conflit de merge sans paniquer.
Comprendre rebase vs merge et quand utiliser quoi.
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

Nommage de branche : type/description-courte → feat/, fix/, chore/, docs/, refacto/. Ex. fix/partition-orders.
Messages de commit (Conventional Commits) : type(scope): description à l'impératif présent.
- feat(bigquery): partitionne orders par date
- fix(dbt): corrige le test unique sur sale_id
- docs(onboarding): ajoute le module airflow
PR : titre clair, description = quoi + pourquoi + comment tester, petite si possible, liée au ticket.

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 :

git restore <fichier> : jeter les modifs non commitées d'un fichier.
git revert <commit> : créer un commit qui annule un commit déjà poussé (sûr, garde l'historique).
git reset : déplacer HEAD (puissant mais dangereux sur du poussé — à éviter en partagé).

Module 4 — Rebase vs merge

Merge (git merge main) : fusionne et crée un commit de merge. Historique fidèle mais touffu.
Rebase (git rebase main) : rejoue tes commits au-dessus de main → historique linéaire, propre.
Règle pratique : rebase ta branche locale pour rester à jour sur main ; merge (ou squash-merge) pour intégrer la PR.
⚠️ Ne jamais rebaser une branche partagée que d'autres ont déjà tirée (réécrit l'historique).

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 :

Lint / format (sqlfluff, dbt parse, terraform fmt -check).
Tests (dbt build sur un dataset CI, tests unitaires).
Build (compilation Go, image Docker).
Plan (terraform plan en commentaire de PR).

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

Tu démarres une correction de bug sur la table orders. Donne le nom de branche + le 1er message de commit (conventions équipe).
git pull te met un conflit sur models/stg_orders.sql. Décris les 3 étapes pour le résoudre.
Tu as poussé un commit qui casse la prod. Quelle commande pour l'annuler sans réécrire l'historique ?
Ta branche a 10 commits de retard sur main. Rebase ou merge pour te remettre à jour, et pourquoi ?
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

Skills équipe : git, git-standards.
Conventional Commits, GitHub Flow.
Lien recette : la CI verte est un prérequis ; Bill recoupe le livrable avant go (recette de code avant commit/déploiement).