Comment gérer un hotfix proprement ?

Sans faire foiré tout le reste de son joli travail!

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour,

J'ai vu que dans le workflow git il fallait utiliser une branches hotfixes pourriez vous m'en décrire la démarche?

J'ai cru comprendre que ZdS faisait ainsi, est-ce bien ça et est-ce bien bon ? :

  • Création de la branche de hotfix sur un fork privé
  • Commit du débugage
  • PR sur la branche de Prod du projet officiel
  • Acceptation sur la branche de prod (merge branch sur prod)
  • git checkout develop (je pense)
  • git rebase upstream/prod (je pense)

Merci de m'aider =)

J’adorerais changer le monde, mais ils ne veulent pas me fournir le code source…

+0 -0

Pour les étapes 1 à 4 oui presque :

  1. Création de la branche de hotfix sur un fork privé
  2. Commit du débugage
  3. PR sur la branche de release/hotfix du projet officiel
  4. Acceptation sur la branche de prod (merge branch sur prod)

cf. http://zds-site.readthedocs.org/fr/latest/workflow.html#workflow-general

Après pour tes points 5 et 6 que souhaite tu achever ?

ZdS, le best du Zeste ! Tuto Arduino, blog, etc

+0 -0
Auteur du sujet

Après pour tes points 5 et 6 que souhaite tu achever ?

Eskimon

Je souhaite que le correctif fasse effet sur la branche de dev pour ne pas géner les développeur non plus.

Car à l'étape 4 tu te retrouve avec un commit sur la branche de prod qui n'existe pas encore sur la branche de dev :/

Donc en suivant ton schéma on devrait peut être faire comme ça ?

  1. Création de la branche de hotfix sur un fork privé
  2. Commit du débugage
  3. PR sur la branche de release/hotfix du projet officiel
  4. Acceptation sur la branche de prod (merge branch sur prod)
  5. Acceptation sur la branche de dev (merge branch sur dev)

Édité par Sanoc

J’adorerais changer le monde, mais ils ne veulent pas me fournir le code source…

+0 -0

Cette réponse a aidé l'auteur du sujet

Je souhaite que le correctif fasse effet sur la branche de dev pour ne pas géner les développeur non plus.

Sanoc

Si c'est suffisamment peu urgent pour des considérations comme « ne pas gêner les développeurs » ou « ça doit faire effet sur la branche de dev », c'est que ce n'est pas un hotfix mais un correctif standard. Un hotfix, par définition, c'est un correctif tellement urgent qu'il doit passer par-dessus toutes les procédures habituelles.

Car à l'étape 4 tu te retrouve avec un commit sur la branche de prod qui n'existe pas encore sur la branche de dev :/

Sanoc

Le hotfix est mergé sur toutes les branches « de référence » en cours : master/prod (forcément), mais aussi dev/develop et l'éventuelle branche de release en cours.

Les textes du renard – Zestes de concerts – Un renard au Japon – Votre dose quotidienne de renards

+1 -0
Auteur du sujet

Ok, merci de l'information.

Mais du coups si tu a par exemple un gros bug de label bien dégeulasse et que cela ne fait pas professionnel du tout. Hotfix ou pas ?

EDIT:

AH non c'est un bugfix dans le gitflow, donc correction sur la branch de release et merge de release du dev/develop.

Édité par Sanoc

J’adorerais changer le monde, mais ils ne veulent pas me fournir le code source…

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte