Réparer un incident sans perdre le travail concurrent

Une correction urgente sur la branche principale peut entrer en conflit avec le travail que vous avez déjà commencé. Si vous changez de branche ou réinitialisez une référence sans vérifier vos fichiers, vous risquez de perdre des changements ou de réparer une version qui n’est plus à jour. Vous allez établir des points de sauvegarde, isoler la correction et vérifier la situation avec l’équipe.

Commencez par inventorier l’état local

Avant toute réparation, relevez la branche active, les commits locaux et l’état des fichiers. La commande git status distingue les fichiers modifiés, les nouveaux fichiers non suivis et les changements déjà indexés ; git log vous aide à voir si des commits locaux ne sont pas partagés. Ces vérifications ne remplacent pas une sauvegarde : elles vous disent précisément ce qu’il faut préserver.

git status --short --branch
git branch --show-current
git log -5 --oneline --decorate

La première commande indique la branche et les fichiers modifiés ou non suivis. La deuxième affiche le nom de la branche courante. La troisième montre les derniers commits et les références qui les désignent.

Si votre travail est déjà commité, créez une référence de sauvegarde sur le commit courant avant de changer de branche. Si vous avez aussi des modifications non commitées, cette référence ne les contient pas : placez-les à part avec un stash qui inclut les fichiers non suivis. Notez le nom de votre branche initiale et le message du stash afin de pouvoir retrouver ces éléments après la réparation.

git branch sauvegarde/avant-reparation-incident HEAD
git stash push -u -m "avant-reparation-incident"
git status --short --branch
git stash list

La branche de sauvegarde conserve le commit courant. Le stash conserve les changements suivis et non suivis qui étaient dans l’arbre de travail. Après l’opération, vérifiez que l’arbre de travail est propre et que le stash apparaît dans la liste.

Isoler la réparation de l’activité de l’équipe

Une fois vos changements locaux préservés, récupérez l’état connu du dépôt partagé et préparez une branche dédiée à la réparation. L’exemple suppose que la branche principale distante s’appelle origin/main et que vous avez identifié le commit partagé à annuler. Remplacez le texte entre chevrons par son identifiant réel ; ne lancez pas la commande avec le placeholder.

git fetch origin
git switch -c fix/reparation-incident origin/main
git status --short --branch
git log -5 --oneline --decorate

La branche fix/reparation-incident part du dernier état récupéré de origin/main. Le statut doit confirmer que vous êtes sur cette branche et que l’arbre de travail est propre avant d’appliquer la réparation.

Pour annuler un commit déjà partagé, la réparation prend la forme d’un commit inverse sur cette branche dédiée. Vous avez vu dans la leçon précédente quand choisir git revert plutôt qu’une réécriture locale : ici, préserver l’historique commun est essentiel. Après la commande, inspectez le résultat et exécutez les vérifications adaptées au dépôt avant de proposer la correction.

git revert <commit-a-annuler>
git status --short --branch
git show --stat --oneline HEAD

Git crée un nouveau commit de réparation sur fix/reparation-incident. Le statut permet de vérifier que l’arbre est propre ; git show résume les fichiers touchés par le nouveau commit.

Coordonner avant de réintégrer le travail

Pendant une intervention, un collègue peut publier un autre changement sur la branche principale. Avant de proposer votre correction, récupérez les nouvelles références et comparez votre branche de réparation à la branche partagée ; si celle-ci a avancé, mettez votre branche de travail à jour selon les conventions de l’équipe, puis vérifiez de nouveau le résultat. Prévenez les personnes concernées de l’incident, du commit visé et de la réparation envisagée : plusieurs corrections simultanées peuvent se contredire même si elles sont techniquement valides.

• Examinez la branche, les commits et les fichiers modifiés avant toute intervention.
• Sauvegardez séparément les commits locaux et les changements non commités, y compris les fichiers non suivis.
• Préparez la réparation sur une branche distincte depuis l’état partagé le plus récent.
• Pour un incident publié, ajoutez une correction sans réécrire l’historique partagé.
• Coordonnez la réparation et vérifiez à nouveau l’état du dépôt avant de la proposer.