Cactus modèle ne pas décourager l`utilisation de branches quand ils sont utiles. En particulier, un développeur individuel doit utiliser des branches d`entités à courte durée de vie dans leur référentiel local et les intégrer à l`origine/maître chaque fois qu`il ya quelque chose qui peut être partagée avec tout le monde. Les succursales locales sont juste pour rendre plus facile de se déplacer entre les fonctionnalités tandis que les validations sont testées ou sous revue de code. Permettez-moi de montrer une alternative beaucoup plus simple, que nous pouvons appeler le modèle de cactus. Il obtient le nom du fait que toutes les branches se ramifie à partir d`un tronc large (branche principale) et ne jamais se fusionner en arrière. Le modèle de cactus devrait refléter beaucoup mieux la façon qui se présente naturellement lorsque vous travaillez avec git et en veillant à ce que les principes d`intégration continue sont utilisés. «Un modèle de branchement git réussi» explique comment les validations de fusion non rapides peuvent être pensées comme un moyen de garder toutes les validations liées à une certaine fonctionnalité bien dans un groupe. Ensuite, si vous décidez qu`une fonctionnalité n`est pas pour vous, vous pouvez simplement revenir que l`on commit et que la fonctionnalité entière a été supprimée. Je dirais que c`est une situation vraiment rare que vous retournez une fonctionnalité ou que vous même le faire complètement à droite sur le premier essai. Quand les gens commencent à utiliser Git et se présenter à des branches et à la facilité de branchement, ils peuvent faire quelques recherches Google et très souvent finissent sur un blog sur un modèle de ramification git réussie. Le plus grand problème avec cet article est qu`il se présente comme l`un des premiers dans de nombreuses recherches liées git ramification quand il devrait servir d`avertissement comment ne pas utiliser des branches dans le développement de logiciels.
Les versions obtiennent leurs propres balises ou branches qui sont ramifiées à partir de l`origine/maître. Dans le cas où nous avons besoin d`un correctif, il suffit d`ajouter que la branche de publication et Cherry-Pick à la branche principale, le cas échéant. En utilisant un marquage spécifique et le schéma de dénomination de branchement devrait permettre pour les versions automatiques, mais cela devrait être complètement invisible pour les développeurs dans leur travail quotidien. L`utilisation de branches individuelles (de longue durée) pour les fonctionnalités rend également plus difficile de s`assurer que tout fonctionne ensemble lorsque les modifications sont fusionnées ensemble. Cela est particulièrement prononcé dans le monde d`aujourd`hui où l`intégration continue devrait être la pratique par défaut du développement de logiciels indépendamment de l`ampleur du projet. En intégrant tous les changements régulièrement, vous éviterez les grands problèmes d`intégration qui perdent beaucoup de temps à résoudre, en particulier pour les projets plus importants avec des centaines ou des milliers de développeurs.
