Posté par 16aR .
En réponse au message branches GIT.
Évalué à 2.
Personnellement, j’étais à fond sur cette méthode au début, puis j’ai été face à plusieurs autres méthodes. Dernièrement, après quelques questionnements, j’ai vérifié ce que faisait le créateur de cette méthode: il ne l’utilise sur aucun de ses repo github récents ! Et il faut les chercher les peu de repo où il a utilisé sa propre méthode.
La seule défense que je pourrais avoir, c’est qu’il ne l’utilise que sur des repo privées professionnel d’envergure. Mais même là, j’ai un doute.
Le plus gros problème que je vois, c’est l’utilité de la branche master. Elle ne sert qu’à lister les différentes release. Sauf que je trouve que ça ne sert à rien et c’est même pas cohérent quand on a 2 versions majeures d’une même app.
Imaginons l’exemple d’une app en 2 versions: v2 et v3. v2 était en Node.js, et la v3 a été réécrite en Go.
Quelle est l’idée d’avoir sur master un tag v2.1.1 suivi d’un tag v3.0.0 puis ensuite un v2.2.0 ?
Pas du tout la même stack technique, on passe d’une branche a une stack node, vers du Go puis du node à nouveau ?
Pour cet exemple, je vois plus chaque version majeure sur sa branche de release. Excepté, la branche en cours de développement est sur master.
Seuls les tags garantissent une publication correcte. Le reste, c’est de l’état intermédiaire en plus ou moins bon état.
[^] # Re: Git Flow
Posté par 16aR . En réponse au message branches GIT. Évalué à 2.
Personnellement, j’étais à fond sur cette méthode au début, puis j’ai été face à plusieurs autres méthodes. Dernièrement, après quelques questionnements, j’ai vérifié ce que faisait le créateur de cette méthode: il ne l’utilise sur aucun de ses repo github récents ! Et il faut les chercher les peu de repo où il a utilisé sa propre méthode.
La seule défense que je pourrais avoir, c’est qu’il ne l’utilise que sur des repo privées professionnel d’envergure. Mais même là, j’ai un doute.
Le plus gros problème que je vois, c’est l’utilité de la branche master. Elle ne sert qu’à lister les différentes release. Sauf que je trouve que ça ne sert à rien et c’est même pas cohérent quand on a 2 versions majeures d’une même app.
Imaginons l’exemple d’une app en 2 versions: v2 et v3. v2 était en Node.js, et la v3 a été réécrite en Go.
Quelle est l’idée d’avoir sur master un tag v2.1.1 suivi d’un tag v3.0.0 puis ensuite un v2.2.0 ?
Pas du tout la même stack technique, on passe d’une branche a une stack node, vers du Go puis du node à nouveau ?
Pour cet exemple, je vois plus chaque version majeure sur sa branche de release. Excepté, la branche en cours de développement est sur master.
Seuls les tags garantissent une publication correcte. Le reste, c’est de l’état intermédiaire en plus ou moins bon état.
git-graph