Commit sur la mauvaise branche : que faire ?
Ces blocs sont des cas différents, pas un script unique. Choisissez celui de votre dépôt. Remplacez branches, chemins et VERIFIED_COMMIT avant usage. Les commandes d’annulation concernent seulement leur opération active ; n’exécutez pas les deux alternatives.
Réponse courte
Si vous avez créé un commit sur la mauvaise branche, conservez-le d’abord sur une branche de secours. Appliquez sa modification à la bonne branche avec cherry-pick et contrôlez le résultat. Corrigez ensuite l’origine : reset peut convenir à une pointe privée ; une branche partagée demande généralement un revert. Ce sont deux décisions distinctes.
Exemple et conditions
Cet exemple part d’un seul commit ordinaire, sans merge, à la pointe de main, destiné à une branche feature/fix existante. L’arbre de travail est propre. Remplacez ces noms par les vôtres. Avec plusieurs commits, un merge ou des travaux ultérieurs, identifiez précisément la plage avant d’utiliser le reset de cet exemple.
Examiner avant de modifier
Lisez l’état, la branche actuelle et le graphe récent. Vérifiez les fichiers et le patch, pas seulement le sujet : un commit peut mélanger plusieurs tâches. Conservez son identifiant complet dans SCHOOL_MISTAKE pour le retrouver après un changement de branche. Déterminez si des collègues l’ont déjà reçu avant de réparer main.
git status --short
git branch --show-current
git log -5 --oneline --decorate
git show --stat HEAD
SCHOOL_MISTAKE=$(git rev-parse HEAD)Garder une référence ou un checkout séparé
La branche de secours garde l’objet du commit accessible ; elle ne copie pas les modifications non commitées. Sauvegardez et vérifiez ces dernières séparément, par un commit délibéré, un stash contrôlé ou une copie externe. Stash avec -u inclut les fichiers non suivis, mais pas les fichiers ignorés. Reflog ne conserve pas automatiquement leur contenu.
git branch rescue/wrong-branch "$SCHOOL_MISTAKE"
git show --stat rescue/wrong-branchPremier parcours
Passez à la branche cible et faites cherry-pick de l’identifiant sauvegardé. Git applique le changement et crée généralement un nouveau commit avec un autre identifiant, car son parent change. Examinez le patch et effectuez les vérifications utiles du projet. Ne retirez pas l’original avant de vérifier la cible et de conserver la référence de secours.
git switch feature/fix
git cherry-pick "$SCHOOL_MISTAKE"
git show --stat HEADChoisir l’autre résultat consciemment
Uniquement pour une pointe privée, revenez sur main et vérifiez que HEAD vaut toujours SCHOOL_MISTAKE. Avec un arbre propre et la branche de secours conservée, reset vers le parent retire ce commit de main. Le reset dur remplace également les fichiers suivis. Si main a avancé ou si le commit a été partagé, cette séquence ne convient plus.
git switch main
git status --short
git rev-parse HEAD
git reset --hard "${SCHOOL_MISTAKE}^"Limites et exceptions
Pour une branche partagée, préférez un revert ordinaire sur cette branche. Il ajoute un commit inverse sans supprimer l’historique reçu par les autres. Le cherry-pick cible et le revert d’origine demandent chacun une vérification. Coordonnez les intégrations ultérieures ; ce guide n’est pas une recette de force push automatique.
git switch main
git revert "$SCHOOL_MISTAKE"Conflits et nettoyage
Cherry-pick peut s’arrêter sur un conflit. Lisez status, résolvez et indexez les fichiers concernés, puis continuez ; utilisez cherry-pick --abort si le choix était incorrect. Revert possède ses propres commandes de continuation et d’annulation. Annuler une opération active n’est pas une sauvegarde générale des modifications effectuées en dehors d’elle.
git status
git cherry-pick --abortgit revert --abortVérifier le résultat
Le graphe final doit montrer le changement sur feature/fix et la correction choisie sur main. Comparez les deux patches et l’état de chaque checkout. Gardez rescue/wrong-branch jusqu’à la fin de la revue. Un état propre ne prouve pas que l’application fonctionne encore : vérifiez aussi le comportement affecté.
git log -6 --oneline --decorate --all
git show --stat feature/fix
git status --shortQuestions fréquentes
Plusieurs commits ? Vérifiez ordre, dépendances et plage. Reset --soft ? Il déplace la référence en conservant index et fichiers, mais ne transfère pas seul un commit à une autre branche. Déjà publié ? Commencez par le revert de l’historique partagé et convenez explicitement de toute réécriture exceptionnelle.
Examiner l’opération dans FluxGit
Utilisez l’historique visuel et la vue des modifications de FluxGit pour examiner l’opération et les commits concernés. Gardez les vérifications de branche, de partage et de fichiers locaux de cet exemple. La page de téléchargement présente les builds et plateformes disponibles.