Quelle est la difference entre git merge et git rebase ?

Git merge cree un nouveau commit de fusion qui combine deux branches, en preservant l'historique complet. Git rebase rejoue vos commits par-dessus une autre branche, creant un historique lineaire. Le rebase est plus propre pour les branches de fonctionnalites, tandis que le merge est plus sur pour les branches partagees.

Comment git bisect trouve-t-il le commit qui a introduit un bug ?

Git bisect effectue une recherche binaire dans votre historique de commits. Vous marquez un commit bon connu et un commit mauvais connu, puis bisect extrait le point milieu pour que vous le testiez. Cela reduit l'espace de recherche de moitie a chaque etape, trouvant le commit fautif en O(log n) etapes.

Puis-je recuperer un commit apres avoir execute git reset --hard ?

Oui. Git reflog enregistre chaque modification de HEAD pendant au moins 30 jours. Executez git reflog pour trouver le SHA du commit perdu, puis utilisez git checkout ou git cherry-pick pour le recuperer. Rien de ce qui a ete commite dans Git n'est veritablement perdu tant que le ramasse-miettes n'a pas ete execute.

Que sont les Git hooks et ou sont-ils stockes ?

Les Git hooks sont des scripts qui s'executent automatiquement a des moments precis du flux de travail Git (pre-commit, commit-msg, pre-push, etc.). Ils sont stockes dans le repertoire .git/hooks/. Pour des hooks partages en equipe, utilisez un outil comme Husky ou stockez les hooks dans un repertoire suivi et creez des liens symboliques.

Flux de Travail Avances avec Git : Rebase, Bisect, Hooks et Recuperation

La plupart des developpeurs apprennent git add, git commit et git push — puis s’arretent la. Mais Git est un outil extraordinairement puissant avec des commandes qui peuvent vous faire gagner des heures de travail, vous aider a traquer des bugs en quelques secondes, automatiser le controle de la qualite du code et vous permettre de recuperer des erreurs qui seraient autrement catastrophiques. Ce guide couvre les flux de travail avances de Git qui differencient les utilisateurs ordinaires des utilisateurs experts : rebase interactif, bisect, hooks, recuperation avec reflog, cherry-pick, worktrees et plus encore.

A qui s’adresse ce guide : Cet article suppose que vous etes a l’aise avec les operations Git de base (commit, push, pull, branch, merge). Si vous apprenez encore ces fondamentaux, commencez par la et revenez quand vous serez pret a passer au niveau superieur.

Prerequis

Avant de plonger dans les flux de travail avances, assurez-vous d’avoir :

Git 2.23 ou ulterieur installe (executez git --version pour verifier)
Un depot avec au moins 20 a 30 commits pour vous entrainer
Une familiarite avec les branches et les fusions de base
Un terminal avec lequel vous etes a l’aise (Bash, Zsh, PowerShell)

# Verifier votre version de Git
git --version

# Mettre a jour Git sur Ubuntu/Debian
sudo apt update && sudo apt install git

# Mettre a jour Git sur macOS
brew upgrade git

Conseil : Creez un depot temporaire pour vous entrainer avec ces commandes. Beaucoup d’entre elles reecrivent l’historique, et vous voulez gagner en confiance avant de les utiliser sur du code de production.

Rebase Interactif

Le rebase interactif est sans doute l’outil de modification de commits le plus puissant de Git. Il vous permet de reecrire, combiner, reordonner et supprimer des commits avant de les pousser vers une branche partagee.

Demarrer un Rebase Interactif

Pour modifier les 5 derniers commits :

git rebase -i HEAD~5

Cela ouvre votre editeur avec une liste de commits, du plus ancien au plus recent :

pick a1b2c3d Add user authentication
pick e4f5g6h Fix typo in login form
pick i7j8k9l Add password reset feature
pick m0n1o2p Fix lint errors
pick q3r4s5t Update README

Commandes de Rebase

Chaque ligne de commit commence par une commande. Les plus utiles sont :

pick — Garder le commit tel quel
reword — Garder le commit mais modifier le message
squash — Combiner ce commit avec le precedent (conserve les deux messages)
fixup — Combiner avec le commit precedent (supprime le message de ce commit)
edit — Mettre en pause le rebase a ce commit pour pouvoir le modifier
drop — Supprimer entierement ce commit

Fusionner des Commits (Squash)

L’utilisation la plus courante du rebase interactif est de fusionner plusieurs petits commits en un seul commit significatif :

pick a1b2c3d Add user authentication
fixup e4f5g6h Fix typo in login form
pick i7j8k9l Add password reset feature
fixup m0n1o2p Fix lint errors
drop q3r4s5t Update README

Cela produit deux commits propres au lieu de cinq desorganises.

Reordonner les Commits

Reorganisez simplement les lignes dans votre editeur pour changer l’ordre des commits :

pick i7j8k9l Add password reset feature
pick a1b2c3d Add user authentication

Avertissement : Ne faites jamais de rebase sur des commits qui ont deja ete pousses vers une branche partagee. Reecrire l’historique partage provoque des conflits pour toute votre equipe. Ne faites le rebase que de vos commits locaux non pousses.

Autosquash avec des Commits de Correction

Si vous savez qu’un commit est une correction pour un commit precedent, marquez-le au moment du commit :

# Creer un commit fixup qui se combine automatiquement avec le commit cible
git commit --fixup=a1b2c3d

# Plus tard, autosquash pendant le rebase
git rebase -i --autosquash HEAD~10

Git reordonne automatiquement les commits fixup a cote de leurs cibles et les marque avec fixup.

Git Bisect : Recherche Binaire de Bugs

Quand un bug apparait et que vous ne savez pas quel commit l’a introduit, tester chaque commit un par un est impraticable. git bisect effectue une recherche binaire, trouvant le commit exact en O(log n) etapes.

Bisect Manuel

# Demarrer la bisection
git bisect start

# Marquer le commit actuel comme mauvais (contient le bug)
git bisect bad

# Marquer un commit bon connu (avant que le bug n'existe)
git bisect good v2.0.0

# Git extrait le point milieu -- testez-le
# Si ce commit contient le bug :
git bisect bad

# Si ce commit ne contient pas le bug :
git bisect good

# Repetez jusqu'a ce que Git identifie le premier commit fautif
# Quand c'est termine :
git bisect reset

Pour une plage de 1 024 commits, bisect trouve le coupable en environ 10 etapes.

Bisect Automatise avec un Script

Si vous disposez d’un script de test qui retourne le code de sortie 0 pour bon et une valeur non nulle pour mauvais :

git bisect start
git bisect bad HEAD
git bisect good v2.0.0

# Executer le test automatiquement a chaque etape
git bisect run ./test-script.sh

# Ou utiliser une commande de test specifique
git bisect run npm test -- --grep "login feature"

Git execute le script a chaque point milieu et identifie le commit fautif sans aucune intervention manuelle.

Bisect avec des Criteres Complexes

# Ignorer les commits qui ne peuvent pas etre testes (ex., build casse)
git bisect skip

# Consulter le journal de bisect
git bisect log

# Rejouer une session de bisect depuis un fichier journal
git bisect replay bisect-log.txt

Strategies de Cherry-Pick

Cherry-pick applique un commit specifique d’une branche a une autre sans fusionner la branche entiere. C’est utile pour les hotfixes, le backporting et l’integration selective de fonctionnalites.

Cherry-Pick Basique

# Appliquer un seul commit a votre branche actuelle
git cherry-pick abc1234

# Appliquer plusieurs commits
git cherry-pick abc1234 def5678 ghi9012

# Appliquer une plage de commits (excluant le premier)
git cherry-pick abc1234..ghi9012

Cherry-Pick Sans Commit

# Preparer les modifications mais ne pas les commiter (utile pour combiner plusieurs picks)
git cherry-pick --no-commit abc1234
git cherry-pick --no-commit def5678

# Examiner les modifications combinees, puis commiter
git commit -m "Backport: authentication fixes from develop"

Gerer les Conflits de Cherry-Pick

# Si un conflit survient pendant le cherry-pick :
# 1. Resoudre les conflits dans les fichiers concernes
# 2. Ajouter les fichiers resolus au staging
git add resolved-file.js

# 3. Continuer le cherry-pick
git cherry-pick --continue

# Ou annuler completement le cherry-pick
git cherry-pick --abort

Cherry-Pick pour les Hotfixes

Un schema courant pour les hotfixes en production :

# Sur la branche main, corriger le bug
git checkout main
git checkout -b hotfix/login-crash

# Effectuer la correction et commiter
git commit -am "Fix: prevent null pointer in login handler"

# Fusionner dans main
git checkout main
git merge hotfix/login-crash

# Cherry-pick de la correction vers la branche develop
git checkout develop
git cherry-pick <hotfix-commit-sha>

Git Hooks

Les Git hooks sont des scripts qui s’executent automatiquement a des moments precis du cycle de vie de Git. Ils garantissent la qualite du code, valident les messages de commit et empechent le code defectueux d’entrer dans le depot.

Types de Hooks et Emplacements

Les hooks se trouvent dans .git/hooks/. Les hooks les plus couramment utilises sont :

Hook	Declencheur	Utilisation Courante
`pre-commit`	Avant la creation d’un commit	Linting, formatage, tests
`commit-msg`	Apres la saisie du message de commit	Valider le format du message
`pre-push`	Avant de pousser vers un depot distant	Executer la suite de tests complete
`post-merge`	Apres la completion d’un merge	Installer les dependances
`pre-rebase`	Avant le demarrage d’un rebase	Empecher le rebase sur des branches partagees

Hook Pre-Commit : Linting

#!/bin/sh
# .git/hooks/pre-commit

# Executer ESLint sur les fichiers JavaScript en staging
STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep '\.js$')

if [ -n "$STAGED_FILES" ]; then
    echo "Running ESLint on staged files..."
    npx eslint $STAGED_FILES
    if [ $? -ne 0 ]; then
        echo "ESLint failed. Fix errors before committing."
        exit 1
    fi
fi

# Executer la verification Prettier
STAGED_ALL=$(git diff --cached --name-only --diff-filter=ACM)
if [ -n "$STAGED_ALL" ]; then
    npx prettier --check $STAGED_ALL
    if [ $? -ne 0 ]; then
        echo "Prettier check failed. Run 'npx prettier --write .' first."
        exit 1
    fi
fi

exit 0

Hook Commit-Msg : Conventional Commits

#!/bin/sh
# .git/hooks/commit-msg

COMMIT_MSG_FILE=$1
COMMIT_MSG=$(cat "$COMMIT_MSG_FILE")

# Appliquer le format Conventional Commits
PATTERN="^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert)(\(.+\))?: .{1,72}"

if ! echo "$COMMIT_MSG" | grep -qE "$PATTERN"; then
    echo "ERROR: Commit message does not follow Conventional Commits format."
    echo ""
    echo "Expected: <type>(<scope>): <description>"
    echo "Example:  feat(auth): add password reset endpoint"
    echo ""
    echo "Valid types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert"
    exit 1
fi

exit 0

Hook Pre-Push : Suite de Tests

#!/bin/sh
# .git/hooks/pre-push

echo "Running test suite before push..."
npm test

if [ $? -ne 0 ]; then
    echo "Tests failed. Push aborted."
    echo "Fix failing tests before pushing."
    exit 1
fi

echo "All tests passed. Pushing..."
exit 0

Partager les Hooks avec Votre Equipe

Les hooks dans .git/hooks/ ne sont pas suivis par Git. Pour les partager :

# Option 1 : Stocker les hooks dans un repertoire suivi
mkdir -p .githooks
cp .git/hooks/pre-commit .githooks/

# Configurer Git pour utiliser le repertoire suivi
git config core.hooksPath .githooks

# Option 2 : Utiliser Husky (projets Node.js)
npx husky install
npx husky add .husky/pre-commit "npx lint-staged"

Git Reflog et Recuperation

Le reflog est votre filet de securite. Il enregistre chaque modification de HEAD — commits, rebases, resets, checkouts — pendant au moins 30 jours. Si vous perdez des commits, le reflog est le moyen de les recuperer.

Consulter le Reflog

# Consulter le reflog
git reflog

# La sortie ressemble a :
# a1b2c3d HEAD@{0}: commit: Add new feature
# e4f5g6h HEAD@{1}: rebase -i (finish): returning to refs/heads/main
# i7j8k9l HEAD@{2}: rebase -i (squash): Add user auth
# m0n1o2p HEAD@{3}: reset: moving to HEAD~3

Recuperer Apres un Reset Incorrect

# Vous avez accidentellement execute git reset --hard HEAD~3 et perdu 3 commits
# Etape 1 : Trouver le commit perdu dans le reflog
git reflog

# Etape 2 : Le commit avant le reset se trouve a HEAD@{1}
git checkout HEAD@{1}

# Etape 3 : Creer une branche pour le sauvegarder
git checkout -b travail-recupere

# Ou cherry-pick des commits specifiques
git cherry-pick a1b2c3d

Recuperer Apres un Rebase Incorrect

# Si un rebase a mal tourne, trouver l'etat avant le rebase
git reflog

# Chercher l'entree juste avant "rebase -i (start)"
# Revenir a ce point
git reset --hard HEAD@{5}

Recuperer des Branches Supprimees

# Vous avez supprime une branche avec un travail important
git branch -D feature/travail-important

# Trouver la pointe de la branche dans le reflog
git reflog | grep "travail-important"

# Recreer la branche au SHA trouve
git branch feature/travail-important abc1234

Important : Les entrees du reflog expirent apres 90 jours (30 jours pour les commits inaccessibles). Si vous decouvrez du travail perdu, recuperez-le le plus tot possible. Vous pouvez configurer l’expiration avec git config gc.reflogExpire.

Git Worktree : Developpement en Parallele

Les worktrees vous permettent d’avoir plusieurs branches ouvertes simultanement dans des repertoires separes. Plus besoin de stash, de commits temporaires ou de changements de branche pour examiner un pull request ou corriger un hotfix.

Creer un Worktree

# Extraire une branche dans un nouveau repertoire
git worktree add ../hotfix-branch hotfix/login-fix

# Creer une nouvelle branche dans un worktree
git worktree add -b feature/new-api ../new-api-work

# Lister tous les worktrees
git worktree list

Flux de Travail Pratique avec les Worktrees

# Votre repertoire de travail principal a develop en cours
# Un bug de production arrive -- travaillez dessus sans perturber votre travail actuel

git worktree add ../prod-fix main
cd ../prod-fix

# Corriger le bug sur une nouvelle branche
git checkout -b hotfix/critical-fix
# ... effectuer les modifications, commiter, pousser ...

# Revenir a votre travail de fonctionnalite
cd ../my-project
# develop est exactement la ou vous l'avez laisse

# Nettoyer quand c'est termine
git worktree remove ../prod-fix

Worktree pour la Revue de Code

# Examiner le PR d'un collegue sans quitter votre branche actuelle
git fetch origin
git worktree add ../review-pr-42 origin/feature/user-dashboard

# Ouvrir le worktree dans votre editeur, examiner le code
# Quand c'est termine :
git worktree remove ../review-pr-42

Utilisation Avancee du Stash

Au-dela du simple git stash, il existe des options puissantes pour gerer les modifications en cours.

Stashes Nommes

# Stash avec un message descriptif
git stash push -m "WIP: refactoring auth middleware"

# Lister tous les stashes
git stash list
# stash@{0}: On develop: WIP: refactoring auth middleware
# stash@{1}: On develop: WIP: database migration script

Stash Partiel

# Mettre en stash uniquement des fichiers specifiques
git stash push -m "stash auth changes" src/auth.js src/middleware.js

# Stash interactif -- choisir des hunks individuels
git stash push -p -m "partial stash"

Stash Apply vs. Pop

# Apply conserve le stash dans la liste (sans risque pour reessayer)
git stash apply stash@{0}

# Pop applique et supprime le stash de la liste
git stash pop stash@{0}

# Appliquer un stash a une autre branche
git checkout feature/autre-branche
git stash apply stash@{0}

Creer une Branche depuis un Stash

# Creer une nouvelle branche et y appliquer le stash
git stash branch nouvelle-branche-feature stash@{0}

Cela est particulierement utile quand le stash entre en conflit avec les modifications de la branche actuelle.

Git Blame et Analyse Forensique du Log

Quand vous avez besoin de comprendre pourquoi une ligne de code existe ou de retrouver quand une modification a ete introduite, les outils d’analyse forensique de Git sont indispensables.

Git Blame

# Voir qui a modifie chaque ligne en dernier
git blame src/auth.js

# Blame sur une plage de lignes specifique
git blame -L 10,20 src/auth.js

# Ignorer les modifications d'espaces blancs
git blame -w src/auth.js

# Afficher le commit qui a deplace ou copie la ligne depuis un autre fichier
git blame -C src/auth.js

Recherches Avancees dans le Log

# Chercher dans les messages de commit par mot-cle
git log --grep="authentication" --oneline

# Chercher les modifications d'une fonction specifique
git log -p -S "function loginUser" -- src/

# Chercher les modifications correspondant a une regex
git log -p -G "TODO|FIXME|HACK"

# Consulter l'historique d'un fichier specifique
git log --follow --oneline -- src/auth.js

# Afficher les commits d'un auteur specifique dans une plage de dates
git log --author="JC" --after="2025-01-01" --before="2025-12-31" --oneline

Formats Visuels du Log

# Graphe compact des branches
git log --oneline --graph --all --decorate

# Format personnalise avec date et auteur
git log --pretty=format:"%h %ad | %s%d [%an]" --date=short

# Afficher les statistiques par commit
git log --stat --oneline -10

Strategies de Branchement

Le choix de la bonne strategie de branchement affecte la velocite et la qualite du code de votre equipe.

Git Flow

Git Flow utilise des branches a longue duree de vie pour differentes etapes :

# Branches principales
main        # Code pret pour la production
develop     # Branche d'integration pour les fonctionnalites

# Branches de support
feature/*   # Nouvelles fonctionnalites (branchees depuis develop)
release/*   # Preparation de version (branchee depuis develop)
hotfix/*    # Corrections de production (branchees depuis main)

# Demarrer une fonctionnalite
git checkout develop
git checkout -b feature/user-dashboard

# Terminer une fonctionnalite
git checkout develop
git merge --no-ff feature/user-dashboard
git branch -d feature/user-dashboard

Ideal pour : Les equipes avec des versions planifiees et de multiples environnements.

GitHub Flow

Une alternative plus simple avec une seule regle : tout ce qui est dans main est deployable.

# Creer une branche depuis main
git checkout main
git checkout -b feature/add-search

# Travailler, commiter, pousser
git push -u origin feature/add-search

# Ouvrir un Pull Request, obtenir une revue, fusionner dans main
# Le deploiement se fait automatiquement depuis main

Ideal pour : Les equipes pratiquant le deploiement continu avec des branches a courte duree de vie.

Developpement Base sur le Trunk

Tous les developpeurs commitent dans main (le trunk) frequemment, en utilisant des branches de fonctionnalite a courte duree de vie d’un a deux jours maximum.

# Branche a courte duree de vie (1-2 jours max)
git checkout -b feature/small-change
# ... modifications minimales ...
git push -u origin feature/small-change
# Fusionner dans main rapidement via PR

# Les feature flags controlent les fonctionnalites non publiees
if (featureFlags.newDashboard) {
    renderNewDashboard();
}

Ideal pour : Les equipes a haute velocite avec des pipelines CI/CD solides et une infrastructure de feature flags.

Tableau de Reference des Commandes Git Avancees

Commande	Description	Exemple
`git rebase -i HEAD~N`	Rebase interactif pour les N derniers commits	`git rebase -i HEAD~5`
`git bisect start`	Demarrer une recherche binaire de bugs	`git bisect start`
`git bisect run <script>`	Bisect automatise avec un script de test	`git bisect run npm test`
`git cherry-pick <SHA>`	Appliquer un commit specifique a la branche actuelle	`git cherry-pick a1b2c3d`
`git cherry-pick --no-commit`	Cherry-pick sans commit automatique	`git cherry-pick --no-commit a1b2c3d`
`git reflog`	Afficher l’historique des mouvements de HEAD	`git reflog`
`git worktree add <chemin> <branche>`	Extraire une branche dans un repertoire separe	`git worktree add ../fix main`
`git stash push -m "msg"`	Sauvegarder des modifications avec un message descriptif	`git stash push -m "WIP auth"`
`git stash push -p`	Stash interactif de hunks selectionnes	`git stash push -p`
`git blame -L 10,20 <fichier>`	Blame sur une plage de lignes specifique	`git blame -L 10,20 auth.js`
`git log -S "chaine"`	Trouver les commits qui ajoutent/suppriment une chaine	`git log -S "loginUser"`
`git log -G "regex"`	Trouver les commits correspondant a une regex	`git log -G "TODO\|FIXME"`
`git commit --fixup=<SHA>`	Creer un commit fixup pour l’autosquash	`git commit --fixup=a1b2c3d`
`git config core.hooksPath`	Definir un repertoire de hooks personnalise	`git config core.hooksPath .githooks`

Depannage

Les Conflits de Rebase Ne Se Resolvent Pas

# Si un rebase a trop de conflits, annuler et essayer une autre approche
git rebase --abort

# Alternative : utiliser merge au lieu de rebase pour les historiques complexes
git merge develop

Bisect Donne des Resultats Incorrects

# Si vous avez marque un commit incorrectement, consulter le journal et rejouer
git bisect log > bisect-log.txt
# Modifier le fichier journal pour supprimer l'entree incorrecte
git bisect reset
git bisect replay bisect-log.txt

Les Scripts de Hook Ne S’Executent Pas

# S'assurer que le fichier de hook est executable
chmod +x .git/hooks/pre-commit

# Verifier que la ligne shebang est correcte
head -1 .git/hooks/pre-commit
# Devrait etre : #!/bin/sh ou #!/bin/bash

# Verifier si core.hooksPath remplace l'emplacement par defaut
git config --get core.hooksPath

Impossible de Supprimer un Worktree

# Forcer la suppression d'un worktree avec des modifications non commitees
git worktree remove --force ../old-worktree

# Nettoyer les entrees de worktree obsoletes
git worktree prune

Entree du Reflog Introuvable

# Augmenter le delai d'expiration du reflog avant qu'il ne soit trop tard
git config gc.reflogExpire 180.days
git config gc.reflogExpireUnreachable 90.days

# Si le reflog est vide, essayer fsck pour trouver les commits orphelins
git fsck --unreachable --no-reflogs

Cherry-Pick Resulte en un Commit Vide

# Les modifications existent deja sur la branche cible
# Utiliser --allow-empty pour conserver le commit, ou le passer
git cherry-pick --skip

# Ou verifier si la modification a deja ete appliquee
git log --oneline --all -- path/to/changed/file

Resume

Les flux de travail avances de Git transforment votre facon de gerer le code. Le rebase interactif maintient votre historique de commits propre et significatif. Git bisect transforme une recherche manuelle de bugs en une recherche binaire automatisee. Les Git hooks garantissent le respect des standards de qualite du code avant que du code defectueux n’entre dans le depot. Reflog agit comme votre filet de securite, rendant virtuellement chaque erreur Git recuperable. Cherry-pick et les worktrees offrent la flexibilite necessaire pour travailler entre les branches sans interruption.

La cle, c’est la pratique. Creez un depot de test, effectuez des dizaines de commits et essayez chaque commande de ce guide. Une fois que ces outils seront devenus une seconde nature, vous gererez les situations Git complexes avec confiance.

Pour automatiser vos pipelines de tests et de deploiement apres avoir maitrise ces flux de travail Git, consultez notre guide sur Premiers Pas avec GitHub Actions pour le CI/CD.