Le mauvais déploiement — Gitor

📁 Fichiers

Aucun fichier. Créez-en un !

! ConflitS IndexéM ModifiéU Non suivi

Aucun fichier indexé. Utilisez git add pour indexer vos changements.

📊 Graphe de commitsbranche actuellemain

🏷️ Workflow de release branchAdvanced0/11

📖 Concepts

Release branchUne branche qui stabilise une version spécifique. Vous branchez depuis un commit connu comme bon avant que des features risquées n'aient atterri. Seuls les fixes critiques y sont cherry-pickés.

Cherry-pick dans une releaseLes nouvelles features sur main sont trop risquées pour une release. Utilisez git cherry-pick <hash> pour ne prendre que les commits de fix précis, en ignorant les commits de features plus récents.

Push de la branche et du tagAprès avoir tagué, pushez à la fois la branche (git push origin release/v1.0) et le tag (git push origin v1.0.0). Les tags ne sont pas pushés automatiquement avec les branches.

📖 Histoire

Votre équipe a été occupée : 2 nouvelles features (dashboard, refactor API) et un fix de bug critique ont été pushés sur origin/main. Vous devez livrer la v1.0 avec le fix mais SANS les features inachevées. Vous allez créer une branche de release depuis le dernier commit stable (avant le fix et les features), cherry-picker uniquement le fix, taguer la release et pusher la branche et le tag. Puis vous synchroniserez main, mergerez le fix dedans, et pousserez proprement. C'est le workflow standard de release branch utilisé pour stabiliser une version sans bloquer le développement en cours.

Voyez l'état actuel

Lancez git log --oneline. Main a 3 commits. Le remote en a 3 de plus : un fix de bug (r4d5e6f) et deux features risquées (dashboard, refactor API). On veut seulement le fix pour la release.

● Voyez l'état actuel

○ Fetch les commits du remote

○ Branchez depuis le commit stable

○ Cherry-pickez uniquement le fix

○ Taguez la release

○ Pushez la branche de release

○ Pushez le tag

○ Revenez sur main

○ Pull le dernier main

○ Mergez le fix de release dans main

○ Pushez main

🧩 The Bad DeployNon résolu

📖 Histoire

Commit mmmm2222 "Enable dark mode by default" just broke production — turns out it had a CSS bug that made text invisible. The branch has already been pushed and your teammates have pulled. You cannot rewrite history with reset — that would break everyone's repos. Safely undo the bad commit by creating a new commit that reverses its changes, leaving history intact.

Objectif

Résolvez le problème en utilisant les bonnes commandes Git.

Terminal

🧩 Problem: The Bad Deploy

A commit broke production. Revert it safely without rewriting shared history.

Use the terminal to solve the problem. Results are checked automatically.