Je travaille en petite équipe avec d'autres développeurs distants sur une Railsapplication. Nous commençons à modifier notre gitflux de travail. Nous avons pensé à une structure de ramification comme ci-dessous:
(dev) -> (qa) -> (stag) -> (master)
Mais certains développeurs ont pensé que cela pourrait être moins déroutant pour les nouveaux développeurs qui pourraient automatiquement passer en production sur master. Ils ont pensé plutôt que tout le monde travaille sur le master et crée une branche distincte pour la production.
(master) -> (qa) -> (stag) -> (prod)
On m'a appris que vous vouliez garder maître déployable et ne pas l'utiliser comme développement et des endroits précédents où j'ai travaillé maître est toujours destiné à être déployable pour la production.
Quels seraient les inconvénients de l'utilisation d'une structure de branchement où le maître est activement utilisé pour le développement et où une branche de production distincte est celle que vous utilisez pour les déploiements?
Réponses:
Il n'y a ni avantages ni inconvénients à cette approche. La raison pour laquelle je dis cela est simple: pour Git, cela ne fait aucune différence si vous développez à partir de master ou sortez de master. Vous n'avez même pas besoin de libérer des branches; vous pouvez marquer un commit arbitraire et le libérer à la place.
Le vrai problème ici est le processus et la procédure. Les développeurs les plus âgés qui craignent que le faire dans un sens confondra les nouveaux développeurs doivent être prêts à investir du temps pour expliquer ce qu'est le modèle de version et pourquoi il en est ainsi.
Tant que tout le monde comprend que master est pour le développement, et qu'une autre branche arbitraire est pour les versions, et que le travail pour le maintenir est fait , alors il ne devrait pas y avoir de problème avec cette approche.
la source
Je peux voir votre dilemme. Je l'avais aussi, jusqu'à ce que j'apprenne ce que je pensais toujours du maître.
De la documentation / livre de Git - Git branching
Donc, si vous avez un flux de travail préféré et qu'il est difficile de travailler avec lui car les différents développeurs de l'équipe ont des idées différentes
master. Vous pourriez même envisager de renommermasterpour direprodet utiliser un flux de travail comme ci-dessous -Voici comment vous changez le nom de la branche principale .
Je ne dis pas que vous devez changer le
masternom de la succursale. Mais si vous avez un flux de travail préféré et que cela aide à changer lemasternom de la branche, faites-le par tous les moyens :-)la source
Je préfère les vérifications aux conventions dans ce cas. Chaque équipe comprend des membres qui sont mieux à même de démarrer de nouvelles fonctionnalités et d'autres personnes qui sont mieux à stabiliser les choses pour une version.
Si vous n'avez pas ce dernier, alors les révisions de code vous aideront (souvent, les personnes les plus disciplinées voudront de toute façon des révisions de code).
C'est pourquoi nous configurons notre référentiel Git (nous utilisons Gitlab) pour que seules certaines personnes puissent fusionner les demandes de tirage et chaque développeur obtient sa propre fourchette privée du référentiel principal.
Cela résout deux problèmes:
Les nouveaux développeurs ne peuvent pas changer la mauvaise branche (car ils ne peuvent pas pousser leur travail directement dans le référentiel principal). Ils peuvent pousser
mastersur leur propre dépôt, mais cela sera corrigé lorsque la demande de tirage arrivera.Les conventions de code se répandent rapidement dans l'équipe puisque chaque validation est vérifiée par au moins une autre personne qui apporte son point de vue et ses connaissances.
la source
Tout dépend du processus global de développement logiciel. La gestion de la configuration et la création d'une nouvelle version ne peuvent être définies sans connaître le processus global.
Il y a la faction "agile" qui opterait pour une "première zone de commit toujours active". Ils exécuteraient des installations automatisées de construction et de test en permanence dans cette zone et essaieraient d'avoir un système fonctionnel "à tout moment".
Ils verraient le (master) -> (release) avec peut-être 1,2 organisation d'étapes intermédiaires comme bénéfique.
Ensuite, il y a la faction plus "classique", qui a un processus guidé par la planification et les étapes d'intégration planifiées vers les jalons, où une version "unité de travail" est une activité planifiée avec des exigences telles que "uniquement la version quand elle est (unité) testée et censé correspondre à la prochaine étape prévue ". Là, la planification comprend la gestion des versions des «unités de travail» et, en général, elles vont très loin pour définir à quoi la prochaine version prévue du produit doit ressembler en termes de fonctionnalités et de correctifs. Pour des raisons de planification, ils veulent savoir que ce qu'un développeur publie est "approprié" et un acte conscient d'engager une unité de travail.
Cette approche classique ne signifie pas nécessairement qu'il y a des périodes plus longues où il n'y a pas de version complète du produit disponible.
Le workflow "classique" serait donc: (dev) -> (unit) -> (integration) -> (test / qa) -> (production).
Le rôle de l'intégrateur est d '«accepter / acheter» les unités publiées ou de les rejeter si elles ne correspondent pas aux besoins de la prochaine version à venir.
Il est également possible de mélanger ces 2 approches de base de manière opportune.
D'après mon expérience (qui était principalement dans le domaine de l'utilisation de l'approche "classique"), l'approche "classique" fonctionnait assez bien dans des projets d'environ 4 à 50 personnes en équipe.
la source