Git Flow attribue des numéros de version en fonction des balises. Il est donc impossible de conserver plusieurs versions actives.
Par exemple :
HashData a publié la version 1.0, suivie de la version 1.1. À ce moment-là, j'ai trouvé un bug dans la version 1.0, qui a été corrigé dans la version 1.1. Les utilisateurs de la version 1.0 ont besoin d'un correctif, mais ne souhaitent pas passer à la version 1.1 (les mises à niveau majeures nécessitent des frais supplémentaires). Que dois-je faire si je dois publier une version 1.0.1 ?
La réponse est que git flow ne peut pas le faire. Vous devez créer une nouvelle branche 1.0.1 à partir de la balise 1.0, ce qui n'est pas dans les règles de git flow.
Git flow est donc plus adapté aux projets avec une seule version active, comme les sites Web. Les produits logiciels traditionnels doivent maintenir plusieurs versions actives en même temps. Donc sans objet.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Git Flow attribue des numéros de version en fonction des balises. Il est donc impossible de conserver plusieurs versions actives.
Par exemple :
HashData a publié la version 1.0, suivie de la version 1.1.
À ce moment-là, j'ai trouvé un bug dans la version 1.0, qui a été corrigé dans la version 1.1. Les utilisateurs de la version 1.0 ont besoin d'un correctif, mais ne souhaitent pas passer à la version 1.1 (les mises à niveau majeures nécessitent des frais supplémentaires). Que dois-je faire si je dois publier une version 1.0.1 ?
La réponse est que git flow ne peut pas le faire.
Vous devez créer une nouvelle branche 1.0.1 à partir de la balise 1.0, ce qui n'est pas dans les règles de git flow.
Git flow est donc plus adapté aux projets avec une seule version active, comme les sites Web. Les produits logiciels traditionnels doivent maintenir plusieurs versions actives en même temps. Donc sans objet.