GUIDE TECHNIQUE · GITHUB
Git avancé : branches, rebase et cherry-pick sur GitHub
Comprendre et utiliser les branches Git, les historiques, le rebase et cherry-pick pour préparer une pull request lisible sans réécrire les contributions d’autres développeurs.
L’ESSENTIEL EN BREF
Les étapes clés
Ce guide présente 6 étapes, de « Lire l’historique avant d’intervenir » à « Publier une pull request sans risque pour les autres ».
Avant de commencer : Un dépôt de recette et une branche personnelle sans changements non committés.
01 · CADRAGE
Périmètre et résultat visé
Résultat attendu : La branche de travail n’inclut que les commits attendus.
Public concerné : Développeurs confirmés, tech leads et ingénieurs DevOps
Git CLI récent sur un dépôt de recette GitHub ; commandes utilisées sur une branche de travail privée et avec un espace de travail propre.
Contrôlez les versions, les droits et les options disponibles dans votre environnement avant de suivre la procédure.
02 · AVANT DE COMMENCER
Prérequis et points de contrôle
- Un dépôt de recette et une branche personnelle sans changements non committés.
- Connaître le nom de la branche principale du dépôt (main dans ces exemples).
- Comprendre la différence entre commits locaux et commits déjà partagés avec d’autres contributeurs.
- Disposer d’une branche de sauvegarde avant toute réécriture de l’historique.
03 · VUE D’ENSEMBLE
Comprendre l’architecture et les flux
04 · TUTORIEL
Procédure complète, étape par étape
Suivez les étapes dans l’ordre et contrôlez chaque résultat avant de poursuivre. Renseignez les paramètres adaptés à votre environnement.
ÉTAPE 1 / 6
Lire l’historique avant d’intervenir
Une opération sur le mauvais commit peut déplacer des changements qui ne vous appartiennent pas.
- Vérifier la branche active et l’état des fichiers.
- Afficher le graphe local et distant.
- Récupérer la dernière référence de main.
git status --short
git branch --show-current
git fetch origin
git log --graph --oneline --decorate --all -15À vérifier : Le graphe expose les commits de la branche et de main.
Point de vigilance : Ne pas intervenir sur une branche partagée sans prévenir ses contributeurs.
ÉTAPE 2 / 6
Créer une branche privée depuis main
Isoler les modifications facilite la revue et le retour arrière.
- Basculer sur main sans changement local.
- Mettre main à jour par fast-forward.
- Créer une branche nommée pour le sujet.
git switch main
git pull --ff-only origin main
git switch -c feature/mon-sujetÀ vérifier : La nouvelle branche est créée au dernier commit connu de main.
Point de vigilance : Ne pas utiliser git reset --hard pour nettoyer un espace de travail contenant des modifications.
ÉTAPE 3 / 6
Comparer les changements avec main
Avant un rebase, il faut identifier exactement les commits à rejouer.
- Comparer les divergences.
- Relire les différences introduites.
- Sauvegarder un pointeur vers l’état courant.
git log --oneline origin/main..HEAD
git diff --stat origin/main...HEAD
git branch sauvegarde/avant-rebaseÀ vérifier : Les commits propres à la branche sont connus et la sauvegarde est créée.
Point de vigilance : La sauvegarde est une branche locale, pas une stratégie de sauvegarde des fichiers non committés.
ÉTAPE 4 / 6
Rebaser uniquement la branche privée
Le rebase rejoue les commits sur main et facilite une historique linéaire avant la revue.
- Vérifier que personne d’autre n’utilise cette branche.
- Lancer le rebase sur main.
- Résoudre les éventuels conflits ; sinon annuler sans perte avec --abort.
git fetch origin
git rebase origin/main
# En cas de conflit, corriger les fichiers puis :
git add chemin/du-fichier
git rebase --continue
# Ou annuler : git rebase --abortÀ vérifier : Les commits privés suivent la dernière version de main.
Point de vigilance : Le rebase réécrit les SHA : ne jamais rebaser une branche collaborative sans accord préalable.
ÉTAPE 5 / 6
Utiliser cherry-pick de manière ciblée
Il permet de réappliquer un correctif précis sur une autre branche sans fusionner tous les travaux.
- Identifier le SHA du commit source.
- Créer une branche de correctif à partir de main.
- Appliquer le commit puis vérifier les différences.
git switch main
git pull --ff-only origin main
git switch -c fix/correctif-isole
git cherry-pick <sha-du-commit>
git show --stat --oneline HEADÀ vérifier : Seul le correctif voulu est présent sur la branche cible.
Point de vigilance : Cherry-pick peut générer des conflits et crée un nouveau commit ; éviter de réappliquer un changement déjà intégré.
ÉTAPE 6 / 6
Publier une pull request sans risque pour les autres
La revue et les contrôles CI assurent une intégration gouvernée.
- Pousser la branche de correctif ou de fonctionnalité.
- Ouvrir la pull request et vérifier le diff.
- Préserver les branches partagées et ne pas forcer leur réécriture.
git push --set-upstream origin fix/correctif-isole
# Ouvrir une pull request vers main et contrôler les Checks.À vérifier : La pull request contient exclusivement les changements attendus.
Point de vigilance : Un push --force, même avec --force-with-lease, peut perturber les branches partagées ; éviter cette opération dans ce tutoriel.
RÉFÉRENCES TECHNIQUES
Documentation officielle
Retrouvez les prérequis, les fonctionnalités et les versions prises en charge par GitHub. Vérifiez les commandes sur un environnement de test avant leur utilisation en production.
05 · RECETTE
Comment vérifier que tout fonctionne ?
La branche de travail n’inclut que les commits attendus.
Une sauvegarde locale précède le rebase.
Une annulation par git rebase --abort est possible pendant une résolution de conflit.
Les changements proposés dans la PR correspondent au diff relu.
06 · DIAGNOSTIC
Problèmes fréquents et résolution
git pull refuse la fusion
Cause probable : Historique divergent ou modifications locales
Que faire : Relever l’état avec git status et choisir une stratégie adaptée au dépôt.
Rebase bloqué
Cause probable : Conflit sur un fichier modifié dans les deux branches
Que faire : Résoudre les marqueurs, git add puis git rebase --continue ; sinon --abort.
Cherry-pick vide
Cause probable : Correctif déjà présent ou entièrement résolu
Que faire : Vérifier le diff avant d’utiliser git cherry-pick --skip.
Push rejeté
Cause probable : Branche distante avancée ou protection active
Que faire : Consulter les changements distants et éviter de forcer une branche commune.
07 · QUESTIONS PRATIQUES
Questions fréquentes
Rebase ou merge ?
Un rebase réécrit les commits d’une branche privée ; un merge crée une convergence explicite de branches. La stratégie dépend des règles du dépôt.
Pourquoi créer une branche de sauvegarde ?
Elle conserve un pointeur vers l’historique initial avant une réécriture locale.
Cherry-pick fusionne-t-il la branche ?
Non. Il réapplique un ou plusieurs commits choisis sur la branche courante.
Peut-on rebaser main ?
Ce guide concerne exclusivement une branche personnelle ; main doit rester protégé par les règles du dépôt.
AUTRES TECHNOLOGIES
Guides complémentaires
VOTRE ENVIRONNEMENT
Besoin d’aller plus loin sur votre environnement ?
Gouvernance, CI/CD et pratiques DevOps : échangeons sur la sécurité et la fiabilité de vos workflows GitHub.
Échanger avec ADN Consulting