Accueil›Blog›Test technique Git avancé

Guide recrutement data

Test technique Git avancé : rebase, hooks, pre-commit, gitflow

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é.

Data Builder·Juin 2025·8 min de lecture·Data Engineer · Analytics Engineer

Sommaire

Branches et workflow
Merge vs rebase
Rebase interactif
Pre-commit hooks
Cherry-pick et stash
Gestion des urgences
Grille par niveau

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.

1Branches et workflow d'équipe

Question discriminante

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.txt

Protection de main — jamais de push direct, uniquement via Pull Request avec review
Convention de commits — Conventional Commits (feat/fix/refactor/docs/chore) pour l'historique lisible et le changelog automatique
Branch naming — feature/nom-court, fix/issue-123, hotfix/bug-critique
.gitignore — credentials, .env, data/, cache/, __pycache__, .ipynb_checkpoints

2Merge vs Rebase : quand utiliser quoi

Question discriminante

Quelle 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 develop

Merge — préserve l'historique exact, crée des merge commits, idéal pour les branches long-lived
Rebase — historique linéaire, plus lisible, idéal pour les feature branches avant PR
Règle d'or — ne jamais rebaser une branche partagée (main, develop) — cela réécrit l'historique des autres
git pull --rebase — évite les merge commits parasites sur les branches de travail

Signal 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.

3Rebase interactif : réécrire l'historique

Question discriminante

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 pick

squash — fusionner plusieurs petits commits en un seul commit logique
fixup — comme squash mais supprime le message du commit annexe
reword — corriger un message de commit sans modifier le contenu
drop — supprimer un commit entier (attention : perd les modifications)

4Pre-commit hooks : qualité automatisée

Question discriminante

Comment 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-files

detect-private-key — bloque si une clé SSH ou un mot de passe est détecté dans le commit
check-yaml — essentiel pour les DAGs Airflow et les configs dbt (YAML mal formé = pipeline cassé)
black — formatage automatique, supprime les débats de style dans l'équipe
En CI/CD — pre-commit run --all-files peut être exécuté dans la CI pour bloquer les PRs non conformes

Bonne 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.

5Cherry-pick et stash

Question discriminante

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 --tags

cherry-pick — appliquer un commit spécifique sans merger toute la branche, idéal pour les hotfixes
stash — mettre en pause le travail en cours pour changer de contexte rapidement
tags — marquer les versions de déploiement, essentiel pour la traçabilité des pipelines en prod

6Gestion des urgences : reflog et suppression d'info sensibles

Question discriminante

Vous 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

git reflog — journal de tous les mouvements de HEAD, permet de récupérer des commits "perdus"
git filter-repo — outil recommandé pour supprimer des fichiers sensibles de tout l'historique (plus rapide que filter-branch)
git revert vs git reset — revert crée un nouveau commit d'annulation (safe sur shared branches), reset réécrit l'historique (dangereux sur branches partagées)
Règle absolue — ne jamais faire git reset --hard sur main ou develop sauf urgence critique

7Grille par niveau

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

Home›Blog›Advanced Git technical interview

Data hiring guide

Advanced Git technical interview: rebase, hooks, pre-commit, gitflow

Everyone knows how to do a git commit and git push. What distinguishes a Senior Data or Analytics Engineer is their mastery of interactive rebase, pre-commit hooks and a structured team workflow.

Data Builder·June 2025·8 min read·Data Engineer · Analytics Engineer

Contents

Branches and workflow
Merge vs rebase
Interactive rebase
Pre-commit hooks
Cherry-pick and stash
Handling emergencies
Level-based grid

In a data context, Git is not optional — whether for versioning Airflow DAGs, dbt models, Python scripts or notebooks. A Data Engineer who does not master rebase or pre-commit hooks introduces technical debt into the entire team's codebase.

1Branches and team workflow

Discriminating question

How do you organize your branches in a data project with multiple contributors? Describe your gitflow.

A good Git data workflow generally follows the gitflow principle or an adapted variant: a main/master branch for production, a develop branch for integration, feature branches per development.

# Standard gitflow data branch structure
main          # stable production, protected, merge via PR only
develop       # continuous integration
feature/xxx   # one branch per feature/DAG/model
hotfix/xxx    # urgent fix directly from main

# Commit naming conventions
feat: add Salesforce extraction DAG
fix: fix timeout on BigQuery pipeline
refactor: simplify dbt transformations
docs: update billing pipeline README
chore: update requirements.txt dependencies

main protection — no direct push, only via Pull Request with review
Commit convention — Conventional Commits (feat/fix/refactor/docs/chore) for readable history and automatic changelog
Branch naming — feature/short-name, fix/issue-123, hotfix/critical-bug
.gitignore — credentials, .env, data/, cache/, __pycache__, .ipynb_checkpoints

2Merge vs Rebase: when to use which

Discriminating question

What is the difference between git merge and git rebase? In which case do you prefer one over the other?

# MERGE: creates a merge commit, preserves exact history
git checkout develop
git merge feature/my-dag
# → creates a "Merge branch 'feature/my-dag'"

# REBASE: reapplies commits onto a new base, linear history
git checkout feature/my-dag
git rebase develop
# → feature/my-dag commits are reapplied after the last develop commit

# Pull with rebase (recommended to avoid unnecessary merge commits)
git pull --rebase origin develop

Merge — preserves exact history, creates merge commits, ideal for long-lived branches
Rebase — linear history, more readable, ideal for feature branches before PR
Golden rule — never rebase a shared branch (main, develop) — this rewrites others' history
git pull --rebase — avoids parasitic merge commits on working branches

Senior GO signal: the candidate spontaneously explains the golden rule of rebase (do not rebase shared branches) and cites the concrete use case: updating a feature branch before the PR.

3Interactive rebase: rewriting history

Discriminating question

How do you clean up a series of WIP commits before submitting your Pull Request?

Interactive rebase allows you to rewrite local history before sharing your work. It is an essential practice for submitting clean PRs.

# Interactively rebase the last 5 commits
git rebase -i HEAD~5

# The editor opens with options for each commit:
# p, pick   = keep the commit as is
# r, reword = keep but edit the message
# s, squash = merge with previous commit (keeps both messages)
# f, fixup  = merge with previous commit (discards this message)
# d, drop   = delete this commit entirely
# e, edit   = modify the commit (to amend it)

# Example: squash 3 WIP commits into a single clean commit
pick a1b2c3 feat: start Salesforce extraction
s d4e5f6 wip: in progress
s g7h8i9 wip: bug fix

# → becomes a single commit with the pick message

squash — merge several small commits into a single logical commit
fixup — like squash but discards the auxiliary commit message
reword — fix a commit message without changing the content
drop — delete an entire commit (caution: loses changes)

4Pre-commit hooks: automated quality

Discriminating question

How do you ensure code quality before each commit? What is a pre-commit hook?

Pre-commit hooks are scripts executed automatically before each commit. In data engineering, they allow you to lint Python code, validate DAG YAML, and auto-format with Black.

# Installation
pip install pre-commit
pre-commit install  # installs hooks in .git/hooks/

# .pre-commit-config.yaml (at repo root)
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.3.0
    hooks:
      - id: check-yaml          # validates YAML files
      - id: check-json           # validates JSON files
      - id: detect-private-key   # blocks if a private key is detected
      - id: check-added-large-files  # blocks files > 500KB
      - id: trailing-whitespace
      - id: end-of-file-fixer

  - repo: https://github.com/psf/black
    rev: 22.10.0
    hooks:
      - id: black               # automatic Python formatting

  - repo:

Test technique Git avancé : rebase, hooks, pre-commit, gitflow

1Branches et workflow d'équipe

2Merge vs Rebase : quand utiliser quoi

3Rebase interactif : réécrire l'historique

4Pre-commit hooks : qualité automatisée

5Cherry-pick et stash

6Gestion des urgences : reflog et suppression d'info sensibles

7Grille par niveau

Advanced Git technical interview: rebase, hooks, pre-commit, gitflow

1Branches and team workflow

2Merge vs Rebase: when to use which

3Interactive rebase: rewriting history

4Pre-commit hooks: automated quality

Vous recrutez un Data Engineer ou Analytics Engineer ?