1. Quelle est la difference 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, creant un historique lineaire plus propre. Le merge est prefere 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. Regle d'or : ne jamais rebase une branche publique.
2. Comment annuler un commit deja pousse sur le depot 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 methode 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 developpeurs. En production, toujours privilegier git revert.
3. Expliquez le fonctionnement du staging area (index) dans Git.
Le staging area (ou index) est une zone intermediaire entre le repertoire de travail et le depot. 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 selectionner precisement quels changements inclure dans un commit, meme 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 resoudre ?
Un conflit survient quand deux branches modifient les memes lignes d'un fichier. Git ne peut pas determiner automatiquement quelle version garder. Les fichiers en conflit sont marques avec des delimiteurs (<<<<<<<, =======, >>>>>>>). Pour resoudre : ouvrez chaque fichier en conflit, choisissez les modifications a 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 resolution visuelle.
5. Quelle est la difference entre git fetch et git pull ?
git fetch telecharge les nouvelles donnees du depot distant (commits, branches, tags) sans modifier votre branche de travail. Cela met a jour les references 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 integrer. 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 demarre 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 a chaque etape vous indiquez si le bug est present ou non. L'algorithme converge rapidement : pour 1000 commits, il faut environ 10 etapes. On peut meme 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 specifique d'une branche sur une autre. Utile pour : appliquer un hotfix de main sur une branche de release, recuperer un commit specifique sans merger toute une branche, ou porter un correctif entre plusieurs versions. Syntaxe : git cherry-pick
9. Expliquez les strategies 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. Ideal pour le deploiement continu. Trunk-Based Development : tous les developpeurs commitent sur main/trunk avec des feature flags. Favorise l'integration continue rapide. GitLab Flow : variante avec des branches d'environnement (staging, production). Le choix depend de la taille de l'equipe, la frequence de release et la complexite du projet.
10. Comment gerer les fichiers sensibles et les secrets dans Git ?
Ne jamais commiter de secrets (mots de passe, cles API, tokens). Utiliser .gitignore pour exclure les fichiers sensibles (.env, credentials). Si un secret a ete 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).