Tout le monde sait faire un git commit et git push. Ce qui distingue un Data Engineer ou Analytics Engineer Senior, c'est sa maîtrise du rebase interactif, des hooks pre-commit et d'un workflow d'équipe structuré.
En contexte data, Git n'est pas optionnel — que ce soit pour versionner des DAGs Airflow, des modèles dbt, des scripts Python ou des notebooks. Un Data Engineer qui ne maîtrise pas le rebase ou les hooks pre-commit introduit de la dette technique dans le code de toute l'équipe.
Comment organisez-vous vos branches dans un projet data avec plusieurs contributeurs ? Décrivez votre gitflow.
Un bon workflow Git data suit généralement le principe gitflow ou une variante adaptée : une branche main/master pour la production, une branche develop pour l'intégration, des feature branches par développement.
# Structure de branches type gitflow data
main # production stable, protégée, merge via PR uniquement
develop # intégration continue
feature/xxx # une branche par fonctionnalité/DAG/modèle
hotfix/xxx # correctif urgent directement depuis main
# Conventions de nommage commits
feat: ajout du DAG extraction Salesforce
fix: correction timeout sur le pipeline BigQuery
refactor: simplification des transformations dbt
docs: mise à jour README pipeline facturation
chore: mise à jour dépendances requirements.txtQuelle est la différence entre git merge et git rebase ? Dans quel cas préférez-vous l'un à l'autre ?
# MERGE : crée un commit de merge, préserve l'historique exact
git checkout develop
git merge feature/mon-dag
# → crée un "Merge branch 'feature/mon-dag'"
# REBASE : réapplique les commits sur une nouvelle base, historique linéaire
git checkout feature/mon-dag
git rebase develop
# → les commits de feature/mon-dag sont réappliqués après le dernier de develop
# Pull avec rebase (recommandé pour éviter les merge commits inutiles)
git pull --rebase origin developSignal GO Senior : le candidat explique spontanément la règle d'or du rebase (ne pas rebaser les branches partagées) et cite le cas d'usage concret : mettre à jour une feature branch avant la PR.
Comment nettoyez-vous une série de commits WIP avant de soumettre votre Pull Request ?
Le rebase interactif permet de réécrire l'historique local avant de partager son travail. C'est une pratique indispensable pour soumettre des PRs propres.
# Rebaser les 5 derniers commits de manière interactive
git rebase -i HEAD~5
# L'éditeur s'ouvre avec les options pour chaque commit :
# p, pick = conserver le commit tel quel
# r, reword = conserver mais modifier le message
# s, squash = fusionner avec le commit précédent (conserve les deux messages)
# f, fixup = fusionner avec le commit précédent (supprime ce message)
# d, drop = supprimer ce commit entièrement
# e, edit = modifier le commit (pour l'amender)
# Exemple : squasher 3 commits WIP en un seul commit propre
pick a1b2c3 feat: début extraction Salesforce
s d4e5f6 wip: en cours
s g7h8i9 wip: correction bug
# → devient un seul commit avec le message de pickComment garantissez-vous la qualité du code avant chaque commit ? Qu'est-ce qu'un pre-commit hook ?
Les pre-commit hooks sont des scripts exécutés automatiquement avant chaque commit. En data engineering, ils permettent de linter le code Python, valider le YAML des DAGs, formater automatiquement avec Black.
# Installation
pip install pre-commit
pre-commit install # installe les hooks dans .git/hooks/
# .pre-commit-config.yaml (à la racine du repo)
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.3.0
hooks:
- id: check-yaml # valide les fichiers YAML
- id: check-json # valide les fichiers JSON
- id: detect-private-key # bloque si une clé privée est détectée
- id: check-added-large-files # bloque les fichiers > 500KB
- id: trailing-whitespace
- id: end-of-file-fixer
- repo: https://github.com/psf/black
rev: 22.10.0
hooks:
- id: black # formatage automatique Python
- repo: https://github.com/pycqa/pylint
rev: v2.15.5
hooks:
- id: pylint
args: ["--fail-under=8"] # score minimum Pylint
# Exécuter manuellement sur tous les fichiers
pre-commit run --all-filesBonne pratique : detect-private-key est non-négociable dans un projet data. Les credentials pushés accidentellement sont la première cause de failles de sécurité dans les repos data.
Dans quel cas utilisez-vous git cherry-pick ? Et git stash ?
# CHERRY-PICK : appliquer un commit spécifique depuis une autre branche
git cherry-pick a1b2c3d # applique le commit a1b2c3d sur la branche courante
# Cas d'usage : un fix urgent est sur feature/X mais doit aller en prod maintenant
git checkout main
git cherry-pick a1b2c3d # récupère uniquement ce fix
# STASH : mettre de côté des modifications en cours
git stash push -m "WIP extraction Salesforce" # sauvegarde et nettoie le working dir
git pull origin develop # récupère les mises à jour
git stash pop # réapplique les modifications sauvegardées
# Lister les stashs
git stash list
# TAGS : marquer une version de déploiement
git tag -a v1.2.0 -m "Pipeline facturation stable"
git push origin --tagsVous avez poussé un mot de passe par erreur dans le repo. Que faites-vous ?
La première action est toujours de changer le mot de passe immédiatement — avant même de nettoyer le repo. Ensuite, supprimer la trace de l'historique.
# Étape 1 : CHANGER LE MOT DE PASSE IMMÉDIATEMENT (avant toute chose)
# Étape 2 : Supprimer le fichier sensible de tout l'historique
pip install git-filter-repo
git filter-repo --invert-paths --path secrets.yaml
git push origin --force --tags
# Récupérer des commits supprimés par erreur (git reflog)
git reflog # liste tous les mouvements de HEAD
git reset --hard HEAD@{3} # revient à l'état 3 étapes en arrière
# Annuler un commit déjà poussé sans réécrire l'historique
git revert HEAD # crée un nouveau commit qui annule le précédent| Niveau | Maîtrise attendue | Signal GO | NO-GO |
|---|---|---|---|
| Junior | add, commit, push, pull, branches simples, résolution de conflits basique | Sait créer une branche, faire une PR, résoudre un conflit simple | Ne sait pas ce qu'est une branche, confond git pull et git fetch |
| Confirmé | Rebase, cherry-pick, stash, .gitignore avancé, gitflow | Explique merge vs rebase, utilise git rebase -i pour nettoyer ses commits avant PR | Ne connaît pas le rebase interactif, n'utilise pas de conventions de commits |
| Senior | Pre-commit hooks, submodules, tags de version, gestion des urgences | A configuré pre-commit avec black + detect-private-key, sait utiliser git reflog | N'a jamais configuré de hooks pre-commit, ne sait pas supprimer un fichier sensible de l'historique |
| Lead | Standards Git équipe, CI/CD pipeline validation, politique de merge | A défini les conventions de commits et la politique de merge pour une équipe, a intégré pre-commit dans la CI | Ne peut pas expliquer sa politique de protection des branches |
Premier entretien gratuit. Rapport GO/NO-GO sous 48h.