1. Quelle est la différence entre git merge et git rebase ?
git merge cree un nouveau commit de fusion qui combine deux branches. L'historique reste intact avec tous les commits des deux branches. git rebase reapplique les commits d'une branche sur une autre, créant un historique linéaire plus propre. Le merge est préfère pour les branches partagees car il ne reecrit pas l'historique. Le rebase est utile pour nettoyer l'historique avant de fusionner une branche de feature. Règle d'or : ne jamais rebase une branche publique.
2. Comment annuler un commit déjà pousse sur le dépôt distant ?
Deux approches principales : git revert cree un nouveau commit qui annule les changements du commit cible, sans modifier l'historique existant. C'est la méthode recommandee pour les branches partagees. git reset --hard suivi de git push --force reecrit l'historique, ce qui est dangereux sur une branche partagee car cela peut causer des conflits pour les autres développeurs. En production, toujours privilegier git revert.
3. Expliquez le fonctionnement du staging area (index) dans Git.
Le staging area (ou index) est une zone intermédiaire entre le répertoire de travail et le dépôt. Quand vous modifiez un fichier, le changement est dans le working directory. Avec git add, vous placez les modifications dans le staging area, preparant ainsi ce qui sera inclus dans le prochain commit. Cela permet de sélectionner précisément quels changements inclure dans un commit, même au niveau de portions de fichiers avec git add -p. Le staging area est stocke dans le fichier .git/index.
4. Qu'est-ce qu'un conflit de merge et comment le résoudre ?
Un conflit survient quand deux branches modifient les mêmes lignes d'un fichier. Git ne peut pas déterminer automatiquement quelle version garder. Les fichiers en conflit sont marques avec des delimiteurs (<<<<<<<, =======, >>>>>>>). Pour résoudre : ouvrez chaque fichier en conflit, choisissez les modifications à garder, supprimez les marqueurs de conflit, puis faites git add et git commit. Les outils comme VS Code, IntelliJ ou les merge tools (kdiff3, meld) facilitent la résolution visuelle.
5. Quelle est la différence entre git fetch et git pull ?
git fetch telecharge les nouvelles données du dépôt distant (commits, branches, tags) sans modifier votre branche de travail. Cela met à jour les références distantes (origin/main, etc.). git pull fait un fetch suivi d'un merge (ou rebase si configure). Fetch est plus sur car il permet de voir les changements avant de les intégrer. Bonne pratique : utiliser git fetch puis inspecter les changements avec git log ou git diff avant de merger.
6. Expliquez le concept de git stash et ses cas d'utilisation.
git stash sauvegarde temporairement les modifications non commitees pour nettoyer le working directory. Cas d'utilisation : changer rapidement de branche sans commiter un travail en cours, tester quelque chose sur une branche propre, ou mettre de cote des modifications avant un pull. Commandes utiles : git stash list (voir les stash), git stash pop (restaurer et supprimer), git stash apply (restaurer sans supprimer), git stash drop (supprimer). On peut aussi nommer un stash avec git stash save "message".
7. Comment fonctionne git bisect et quand l'utiliser ?
git bisect permet de trouver le commit qui a introduit un bug par recherche binaire. On démarre avec git bisect start, on marque un commit bon (git bisect good) et un commit mauvais (git bisect bad). Git navigue automatiquement entre les commits, et à chaque étape vous indiquez si le bug est présent ou non. L'algorithme converge rapidement : pour 1000 commits, il faut environ 10 étapes. On peut même automatiser avec git bisect run en fournissant un script de test.
8. Qu'est-ce que le cherry-pick et quand est-il utile ?
git cherry-pick applique un commit spécifique d'une branche sur une autre. Utile pour : appliquer un hotfix de main sur une branche de release, récupérer un commit spécifique sans merger toute une branche, ou porter un correctif entre plusieurs versions. Syntaxe : git cherry-pick
9. Expliquez les stratégies de branching les plus courantes.
Git Flow : branches main, develop, feature, release et hotfix. Adapte aux cycles de release structures. GitHub Flow : plus simple, une branche main et des branches de feature avec pull requests. Idéal pour le déploiement continu. Trunk-Based Development : tous les développeurs commitent sur main/trunk avec des feature flags. Favorise l'intégration continue rapide. GitLab Flow : variante avec des branches d'environnement (staging, production). Le choix dépend de la taille de l'équipe, la fréquence de release et la complexité du projet.
10. Comment gérer les fichiers sensibles et les secrets dans Git ?
Ne jamais commiter de secrets (mots de passe, clés API, tokens). Utiliser .gitignore pour exclure les fichiers sensibles (.env, credentials). Si un secret a été commite par erreur, utiliser git filter-branch ou BFG Repo Cleaner pour le supprimer de tout l'historique, puis forcer le push et faire tourner les credentials compromis. Solutions preventives : pre-commit hooks avec des outils comme git-secrets ou detect-secrets, variables d'environnement, et gestionnaires de secrets (Vault, AWS Secrets Manager).