Questions d'entretien sur Git : 25 questions avec réponses

Git est évalué dans presque tous les entretiens de développeur, de testeur ou d'ingénieur DevOps : parfois dans un bloc dédié, parfois au détour d'une question (« comment annuleriez-vous une release ratée ? »). Le recruteur s'intéresse moins aux options qu'à la compréhension du modèle : ce qu'est un commit, vers quoi pointe une branche, ce qui réécrit l'historique. Voici les 25 questions les plus fréquentes, avec des réponses du niveau qui fait bonne impression.

Les questions vont des bases aux sujets avancés. En entretien, illustrez si possible par un court exemple tiré de votre pratique — c'est plus apprécié qu'une récitation de la documentation.

Questions de base

1. Qu'est-ce que Git et en quoi un système de gestion de versions distribué diffère-t-il d'un système centralisé ?

Git est un système de gestion de versions distribué : il conserve l'historique des modifications d'un projet et permet à plusieurs personnes d'y travailler en parallèle. Dans les systèmes centralisés (SVN par exemple), l'historique complet se trouve sur un seul serveur et le développeur n'a qu'une copie de travail. Dans Git, chaque clone contient tout l'historique : commits, branches, consultation de l'historique et fusions fonctionnent en local, sans réseau.

Avantages pratiques : grande rapidité, travail hors ligne, aucun point de défaillance unique. Un serveur comme GitHub ou GitLab n'est qu'une convention d'équipe sur la copie « principale », pas une nécessité technique.

2. Quelles sont les trois zones de travail de Git ?

Le répertoire de travail (les fichiers sur le disque), l'index ou staging area (l'instantané préparé du prochain commit) et le dépôt local (le dossier .git contenant l'historique). git add fait passer les changements du répertoire de travail à l'index, git commit de l'index au dépôt.

Un bon complément : mentionner la quatrième zone, le dépôt distant, et les commandes git push et git fetch qui travaillent avec lui.

3. À quoi sert l'index si l'on peut commiter directement ?

L'index permet de composer un commit de façon réfléchie : sur dix fichiers modifiés, commiter les trois qui concernent une même tâche et laisser le reste. Avec git add -p, on peut même choisir des fragments à l'intérieur d'un fichier.

C'est la base des commits atomiques : un commit = un changement logique. Un tel historique est facile à lire, à relire, à annuler avec revert et à transférer avec cherry-pick.

4. Qu'est-ce qu'un commit du point de vue du fonctionnement interne de Git ?

Un commit est un objet qui contient une référence vers un arbre (tree) — l'instantané de tous les fichiers du projet —, des références vers les commits parents, l'auteur, le committer, les dates et le message. Il est identifié par un hash SHA-1 (les versions récentes proposent un support expérimental de SHA-256) calculé sur l'ensemble du contenu.

L'idée clé : Git stocke des instantanés, pas des diffs. Les fichiers inchangés ne sont pas dupliqués — l'arbre pointe simplement vers le même blob. Comme le hash dépend du parent, impossible de modifier un ancien commit sans changer les hashes de tous les suivants.

5. Qu'est-ce qu'une branche et qu'est-ce que HEAD ?

Une branche n'est qu'un pointeur mobile vers un commit : un fichier dans .git/refs/heads/ contenant un hash. C'est pourquoi créer une branche dans Git est instantané et ne copie rien. À chaque nouveau commit, le pointeur de la branche courante avance dessus.

HEAD est le pointeur vers l'endroit où vous vous trouvez ; il pointe généralement vers une branche (ref: refs/heads/main). Si vous basculez sur un commit ou un tag précis, HEAD pointe directement vers le commit : c'est l'état detached HEAD.

6. Qu'est-ce que l'état detached HEAD et pourquoi est-il risqué ?

C'est l'état où HEAD pointe vers un commit et non vers une branche, par exemple après git switch --detach v1.0 ou git checkout a1b2c3d. On peut consulter le code et même commiter, mais les nouveaux commits n'appartiennent à aucune branche.

Si vous passez ensuite sur une autre branche, ces commits deviennent inaccessibles et finissent supprimés par le ramasse-miettes. Pour conserver le travail, créez une branche : git switch -c fix-from-detached. Si vous êtes déjà parti, le hash se retrouve dans git reflog.

7. Quelle différence entre git fetch et git pull ?

git fetch télécharge les nouveaux commits et met à jour les branches de suivi distantes comme origin/main, sans toucher à vos branches locales ni à vos fichiers. git pull = fetch + intégration : merge par défaut, rebase avec l'option --rebase ou le réglage pull.rebase=true.

Les développeurs expérimentés font souvent fetch séparément, regardent git log HEAD..origin/main, puis seulement décident comment intégrer les changements.

8. Comment fonctionne .gitignore et pourquoi un fichier reste-t-il suivi alors qu'il y figure ?

.gitignore définit les motifs des fichiers que Git ne doit pas proposer d'ajouter : dépendances, build, logs, configurations locales contenant des secrets. Les règles ne s'appliquent qu'aux fichiers non suivis.

Si le fichier a déjà été commité, l'ignore n'a aucun effet. Il faut le retirer de l'index en le gardant sur le disque : git rm --cached config.local.php, puis commiter cette suppression. Pour savoir quelle règle s'applique : git check-ignore -v chemin.

Branches, fusion et conflits

9. Qu'est-ce qu'un fast-forward merge ?

Si la branche cible n'a pas avancé depuis la divergence, Git se contente lors de la fusion d'avancer son pointeur jusqu'au dernier commit de la branche fusionnée — sans nouveau commit. L'historique reste linéaire.

L'option --no-ff force la création d'un commit de merge même dans ce cas : l'historique montre alors qu'un groupe de commits formait une fonctionnalité. À l'inverse, --ff-only n'autorise que le fast-forward et refuse si une vraie fusion est nécessaire.

10. Comment naît un conflit de fusion et comment le résoudre ?

Un conflit survient quand les mêmes lignes d'un fichier ont été modifiées dans les deux branches (ou qu'un fichier a été supprimé d'un côté et modifié de l'autre) et que Git ne peut pas trancher automatiquement. Il interrompt la fusion et marque les endroits avec <<<<<<<, =======, >>>>>>>.

git status                 # liste des fichiers en conflit
# on modifie les fichiers en gardant la bonne variante
git add app.js
git commit                 # pour un merge ; pour un rebase — git rebase --continue

Une bonne réponse inclut aussi la prévention : petites branches, pull fréquent depuis la branche principale, conventions de formatage. Et git merge --abort pour faire machine arrière.

11. Quelle différence entre merge et rebase ?

merge réunit deux branches en créant un commit de merge à deux parents ; les commits existants ne changent pas, l'historique reflète fidèlement le travail en parallèle. rebase déplace les commits de votre branche au-dessus d'une autre en créant des copies avec de nouveaux hashes ; l'historique devient linéaire.

Règle habituelle : rebase pour ranger sa branche locale avant publication, merge pour intégrer dans les branches partagées. Rebaser des commits publiés sur lesquels d'autres travaillent provoque doublons et confusion.

12. Qu'est-ce que le rebase interactif et à quoi sert-il ?

git rebase -i HEAD~5 ouvre la liste des cinq derniers commits, où l'on choisit une action pour chacun : pick — garder, reword — modifier le message, edit — s'arrêter pour corriger, squash et fixup — fusionner avec le précédent, drop — supprimer. On peut aussi réordonner les lignes.

Scénario type : avant une pull request, transformer « wip », « fix typo », « encore un fix » en deux ou trois commits sensés. Combinaison pratique : git commit --fixup=<hash> puis git rebase -i --autosquash.

13. Que fait un squash merge et quand le choisir ?

Avec un squash merge, tous les commits d'une branche sont compressés en un seul commit dans la branche cible (git merge --squash ou le bouton sur GitHub/GitLab). La branche principale reçoit un commit par fonctionnalité.

Avantage : un historique de main propre. Inconvénient : l'historique détaillé de la fonctionnalité est perdu, et Git ne considère pas la branche source comme fusionnée, si bien que git branch -d refuse de la supprimer sans -D.

14. Qu'est-ce que cherry-pick et quand est-il approprié ?

git cherry-pick <hash> applique les changements d'un commit à la branche courante en créant un nouveau commit au contenu identique mais au hash différent. Cas classique : reporter la correction d'un bug de develop vers une branche de release ou de hotfix.

À ne pas en abuser : un même correctif vit dans deux commits, et une fusion ultérieure des branches peut provoquer des conflits. L'option -x ajoute au message une référence au commit d'origine.

Annulation et récupération

15. Quelle différence entre git reset --soft, --mixed et --hard ?

Mode	Pointeur de branche	Index	Répertoire de travail
--soft	déplacé	inchangé	inchangé
--mixed (par défaut)	déplacé	réinitialisé	inchangé
--hard	déplacé	réinitialisé	réinitialisé, modifications perdues

git reset --soft HEAD~3 est pratique pour refaire les trois derniers commits en un seul. --hard est dangereux pour les modifications non commitées : même le reflog ne les rendra pas.

16. Quelle différence entre git revert et git reset ?

reset ramène le pointeur de branche en arrière, réécrivant de fait l'historique. revert crée un nouveau commit qui annule les changements du commit indiqué et ne réécrit rien.

Pour des commits publiés sur une branche partagée, la bonne réponse est donc revert : l'historique des collègues n'est pas cassé et l'annulation est visible dans le log. Pour un commit de merge, il faut préciser le parent principal : git revert -m 1 <hash>.

17. Comment récupérer des commits après un git reset --hard accidentel ?

Grâce à git reflog : il conserve en local l'historique des déplacements de HEAD et des branches (par défaut, les entrées vivent environ 90 jours). On repère l'entrée d'avant la commande malheureuse et on y revient :

git reflog
# a1b2c3d HEAD@{0}: reset: moving to HEAD~2
# 9f8e7d6 HEAD@{1}: commit: Ajouter le paiement
git reset --hard 9f8e7d6

Réserve importante : le reflog ne sauve que ce qui a été commité. Des modifications jamais entrées dans un commit (ou au moins dans un stash) ne peuvent pas être récupérées avec Git.

18. Comment annuler les modifications d'un fichier et le retirer de l'index ?

Les commandes modernes sont git restore app.js (ramener le fichier à l'état de l'index) et git restore --staged app.js (le retirer de l'index en gardant les modifications). Auparavant, on utilisait git checkout -- app.js et git reset HEAD app.js ; elles fonctionnent toujours.

19. Qu'est-ce que git stash et quels sont ses pièges ?

git stash met temporairement de côté les modifications non commitées et nettoie le répertoire de travail — par exemple pour passer en urgence sur un hotfix. On les récupère avec git stash pop ou apply.

Pièges : par défaut, les fichiers non suivis ne sont pas sauvegardés (il faut -u) ; un pop peut provoquer un conflit, et l'entrée n'est alors pas retirée de la liste ; on oublie facilement un stash. Pour un travail de longue haleine, mieux vaut un commit dans une branche à part.

Questions avancées et travail en équipe

20. Comment trouver le commit qui a cassé une fonctionnalité ?

Avec git bisect — une recherche dichotomique dans l'historique. Vous indiquez un commit mauvais et un bon, et Git vous place au milieu de l'intervalle jusqu'à trouver le coupable en log2(N) étapes.

git bisect start
git bisect bad                 # la version actuelle est cassée
git bisect good v2.3.0         # ici, tout fonctionnait
# on teste et on répond good/bad jusqu'à ce que Git désigne le commit
git bisect reset

Avec un script de test, le processus s'automatise : git bisect run npm test.

21. Pourquoi git push --force est-il dangereux et par quoi le remplacer ?

--force écrase la branche distante avec votre version, et les commits que vos collègues avaient poussés disparaissent du serveur. Plus sûr : git push --force-with-lease, qui n'écrase la branche que si elle est sur le serveur dans l'état que vous avez vu lors du dernier fetch.

Un push forcé est normal sur sa propre branche feature après un rebase ; sur main et les autres branches partagées, il est généralement interdit par la protection des branches côté serveur.

22. Quels workflows Git connaissez-vous ?

GitHub Flow : une branche principale toujours déployable et des branches feature courtes, fusionnées via pull request après revue et CI. Git Flow : les branches main et develop, plus feature/*, release/* et hotfix/* ; adapté aux produits à releases versionnées. Trunk-based development : tout le monde intègre très souvent dans le trunk, et l'inachevé est masqué derrière des feature flags.

Une réponse solide justifie le choix : pour un service web en déploiement continu, Git Flow est généralement excessif ; pour une bibliothèque maintenue en plusieurs versions, il est justifié.

23. Qu'est-ce qu'une pull request et qu'y vérifie-t-on ?

Une pull request (merge request dans GitLab) est une demande de fusion de branche qui passe par une revue de code et des vérifications CI automatiques avant intégration. C'est une fonction de la plateforme (GitHub, GitLab, Bitbucket), pas de Git lui-même.

Une bonne PR est petite, traite une seule tâche, a une description claire et est liée au ticket correspondant. Le relecteur vérifie la justesse, la lisibilité, les tests, et qu'aucun fichier superflu ni secret ne s'y est glissé.

24. Quelles règles suivez-vous pour un bon message de commit ?

Un titre court (50 à 72 caractères maximum) à l'impératif — « Ajouter la validation de l'e-mail » —, puis une ligne vide et un corps qui explique le « pourquoi », pas le « quoi » (ce qui a changé se voit dans le diff). Beaucoup d'équipes utilisent les Conventional Commits : feat:, fix:, docs:, refactor:.

De tels messages permettent de générer un changelog, de retrouver vite l'information via git log --grep et de comprendre les motivations des changements des années plus tard.

25. Que faites-vous si vous avez poussé par erreur un mot de passe dans le dépôt ?

D'abord, révoquer et régénérer le secret : il est déjà compromis, même s'il est supprimé une minute plus tard (clones, forks, caches). Ensuite, retirer le fichier du suivi, l'ajouter au .gitignore et, si nécessaire, nettoyer l'historique avec des outils comme git filter-repo, suivi d'un force push et d'un avertissement à l'équipe.

Le recruteur vérifie ici les priorités : un candidat qui commence par réécrire l'historique et oublie la rotation de la clé répond mal.

Comment se préparer aux questions sur Git

Le plus sûr n'est pas d'apprendre les réponses par cœur, mais de rejouer chaque scénario à la main dans un dépôt de test : créer un conflit et le résoudre, faire un reset --hard et se rattraper avec le reflog, compresser des commits par rebase interactif. En entretien Git, on donne souvent un exercice pratique ou l'on demande de dessiner le graphe des commits avant et après une commande — si vous l'avez fait vous-même, le dessin vient tout seul.

Il est aussi utile de passer un petit quiz Git pour vous auto-évaluer : essayez de dire sans aide ce que devient l'historique après git rebase main ou git revert HEAD. Si vous répondez avec assurance à « que se passe-t-il dans les trois zones », vous avez les bases.

Conclusion

Un entretien Git se ramène presque toujours à trois thèmes : le modèle de données (commits, branches, HEAD, index), l'intégration des changements (merge, rebase, conflits, fetch et pull) et l'annulation sûre (reset, revert, reflog). Ajoutez la compréhension des workflows d'équipe et des pull requests, et vous couvrirez l'immense majorité des questions. Tous ces scénarios, y compris le travail en équipe et les outils avancés, sont pratiqués dans le cours Git.