La tendance de la branche "développer" à disparaître

82

J'ai récemment remarqué quelque chose qui regarde certains projets populaires sur GitHub, à savoir qu'il n'y a pas de developbranche. Et en fait, le guide GitHub Flow ne le mentionne pas non plus. De ma compréhension, masterdevrait toujours être totalement stable et refléter la production. Si les développeurs travaillent sur des branches de fonctionnalités, et les fusionnent ensuite master, cela signifie qu'il y a une période de temps pendant laquelle les fonctionnalités / correctifs sont fusionnés masteret que la masterbranche est en réalité plus récente que la production.

Ne serait-il pas plus logique de demander à l’équipe de créer des branches de fonctionnalités / corrections develop, de les fusionner à nouveau, puis de developfusionner masteret de créer une balise lorsque la version suivante est totalement prête à être commercialisée ? Imaginez que des personnes fusionnent directement masteret qu’un bogue signalé en production devienne difficile à corriger car la masterbase de code de la branche a considérablement changé. Ensuite, les développeurs doivent simplement dire à l'utilisateur d'attendre la prochaine version pour voir le problème résolu.

EDIT: Cette question est différente de celle de "créer ou non une branche". Il s’adresse spécifiquement aux personnes qui abandonnent l’utilisation de la branche develop et aux raisons qui l’entourent, car cela a longtemps été présenté comme la meilleure pratique.

git github ffxsam
la source
11
Il existe de nombreux flux de travail que git permet. Il ne faut pas s’attendre à ce que gitflow ou github flow soit utilisé pour tous les projets.
Question très intéressante. J'ai travaillé des années avec nvie.com/posts/a-successful-git-branching-model et je dois dire que cela me plait. Ce que j’aime le plus, c’est que a) maître est ce qui est en production et que cela s’applique également aux versions; b) il existe une nette différence entre un correctif logiciel et une fonctionnalité, elles sont lancées et fusionnées sur maître et développent respectivement. Cependant, après avoir suivi cette discussion, je commence à avoir des doutes sur le fait de trop compliquer les choses. Des opinions à ce sujet?
Aspasia
1
Je déteste le concept que master est un enregistrement de ce qui est en production. Si nous devons savoir ce qui est en production, nous devrions simplement interroger la production et ne pas nous fier au maître pour refléter avec précision ce qui est en production.
Jim V

Réponses:

52

Il provient de la CI mentalité où il y a intégration plusieurs fois par jour.

Il y a des avantages et des inconvénients des deux.

Au sein de notre équipe, nous avons également abandonné la branche de développement, car nous estimions qu’elle n’apportait aucun avantage supplémentaire, mais quelques inconvénients. Nous avons configuré notre logiciel CI (Teamcity) pour compenser les inconvénients:

  1. Activer le déploiement d'un commit spécifique. En d'autres termes: nous ne déployons pas de branche. Nous déployons un commit.
  2. Nous pouvons déployer le maître ou les branches en commençant par un correctif / préfixe.

Cela fonctionne parce que toutes les demandes d'extraction contiennent du code potentiellement libérable, mais cela ne signifie pas que nous déployons tous les commits en maître.

La raison principale pour laquelle nous avons abandonné la branche développement est qu’elle avait tendance à devenir trop volumineuse et trop longue à voir ce qu’elle contenait. Si nous avons déployé quelque chose un peu prématurément, nous nous contentons de dériver une branche de correctif et de le déployer directement.

Esben Skov Pedersen
la source
11
Ayant travaillé avec une branche de développement pendant un an ou deux, je voulais juste dire: amen, abandonne cette chose:]
mercredi
Intéressant. Je suppose donc que lorsque vous publiez la version 1.3, par exemple, vous balisez un commit spécifique masterafin que, si un bogue survient plus tard alors que vous êtes masterdans un état de flux, vous pouvez facilement détacher un correctif à partir de la balise 1.3?
Ffxsam
5
Je dirais que l’avantage de «développer» dépend en grande partie du type de logiciel que vous créez, de la façon dont il est déployé et de la nécessité de prendre en charge plusieurs versions en direct ou non.
axl
1
@ffxsam, nous n'avons même pas besoin de marquage car nous recherchons quel identifiant git est actuellement déployé. Ceci est enregistré à la fois dans TeamCity, puis dans des dll déployées et dans le portail de gestion azur. Nous n’avons donc pas ressenti le besoin de procéder à un marquage supplémentaire, à l’exception du marquage automatique réalisé par TeamCity. Si vous pensez que le marquage convient mieux à votre flux de travail, il sera également résolu. Mais oui, en principe, quittez directement la modification actuellement déployée pour créer une branche de correctif logiciel.
Esben Skov Pedersen
25

Une branche de développement est plus importante si votre processus de publication est complexe et que vous devez avoir de sérieux candidats à la publication.

Par exemple, imaginez que vous écrivez un logiciel qui est un micrologiciel sur une voiture. Ceci est ... non trivial à corriger et il est probable que toute version aurait un ensemble complet de tests non-CI / d'intégration exécutés sur du matériel réel.

Dans ce cas, il peut être plus logique d'isoler un "candidat à la libération" dans une branche non principale (telle que "develop"). Cela permet à votre équipe exécutant ces tests d’avoir une branche dans laquelle fusionner des fonctionnalités.

Les applications Web ou autres logiciels facilement mis à jour n'ont pas cette contrainte.

Cependant, notez que:

  • Beaucoup (la plupart?) Des projets sur github n'ont pas ce genre de contrainte
  • Un "maître" principal a le même objectif
  • Un workflow de "créer un maître de relations publiques contre un maître de relations publiques" est beaucoup plus universel que de "créer un PR de relations publiques contre une branche que vous ne connaissez pas immédiatement sur ce référentiel"
Enderland
la source
18

J'ai vu deux philosophies dans les projets, et je pense que le choix est une question de goût:

  1. Désignez «maître» comme version de production et développez-le dans une branche «développement».

  2. Développez en «maître» et créez une branche portant des noms différents pour les versions de production stables. Cela est d'autant plus logique si votre projet comporte plusieurs branches de version à la fois (par exemple, la version actuelle préférée est la version 1.8, mais vous conservez également la version 1.7).

Les deux sont des approches communes, et ont leurs avantages et leurs inconvénients.

Larry Gritz
la source
Je suis d'accord avec toi. Nous préférons avoir des branches de publication et les conserver jusqu’à la prochaine publication en production. Si nous devons faire des correctifs, nous vérifions la dernière branche de la version et travaillons dessus, puis fusionnons ces correctifs dans la branche maître / développement
Johnny
Exactement. Ce que «maître» devrait faire, c'est principalement de la sémantique. L'essentiel est de ne pas avoir à synchroniser de manière bidirectionnelle plusieurs branches toujours vivantes, à moins que vous n'ayez une très bonne raison de le faire. La branche "maître" de Git Flow n'est qu'une réplique retardée de "développer", elle ne compte donc pas vraiment. L'anti-pattern permet à la branche principale de développement de gérer des modifications qui ne vont jamais dans une publication, ce qui est une pratique scandaleusement courante que j'ai vue. Les deux modèles mentionnés ci-dessus empêchent cela, c'est pourquoi ils fonctionnent.
John Michelau
7

Les sorties en production peuvent être étiquetées, de sorte que la situation qui a été publiée peut toujours être reproduite sans consacrer une branche entière à cette fin.

Si un bogue critique est détecté dans la production à un moment où le maître ne peut pas être publié, il est assez facile d'extraire le tag et de démarrer une nouvelle branche "correctif pour la version 1.2.0" à partir de là. Mais cela devrait être plutôt rare.

La plupart du temps, dans nos applications Web, master a changé depuis la dernière version, mais pas de manière très significative. Nous pouvons donc simplement créer une nouvelle version de master intégrant le correctif. De toute façon, cela aide de faire des communiqués très fréquents.

RemcoGerlich
la source
5

Si les développeurs travaillent sur des branches de fonctionnalités, puis fusionnent celles-ci dans leur structure principale, cela signifie qu'il y a une période de temps au cours de laquelle les fonctionnalités / correctifs sont fusionnés masteret que la masterbranche est en réalité plus récente que la production.

...

Imaginez que des personnes fusionnent directement dans master et qu’un bogue signalé en production devienne difficile à corriger car la base de code de la branche master a considérablement changé.

Ce n'est pas Github Flow.

Voici le processus de déploiement / fusion de Github Flow, en fonction de votre lien:

Déployer

Une fois que votre demande d'extraction a été examinée et que la branche a réussi vos tests, vous pouvez déployer vos modifications pour les vérifier en production. Si votre branche cause des problèmes, vous pouvez la restaurer en déployant le maître existant en production.

Fusionner

Maintenant que vos modifications ont été vérifiées en production, il est temps de fusionner votre code dans la branche principale.

(Mon accentuation)

En d'autres termes, masterne sera jamais en avance sur la production. De même, mastersera toujours dans un état stable et libérable (mis à part les bogues non découverts), puisque tout est examiné, testé et mis en production avant d’ être fusionné master.

8bittree
la source
Agréable! Cela a un sens intuitif: mastervotre position de retour en arrière est toujours active en cas de défaillance de la branche de fonctionnalité que vous mettez en production. Si ce n'est pas le cas, il est fusionné masteret devient la nouvelle solution de rechange. Je l'aime.
Bill Horvath le
1

Le problème que je vois est que le déploiement / fusion de flux Git / Hub suppose qu'une fonctionnalité est en cours de développement / testée / fusionnée / déployée à la fois - et selon mon expérience, ce n'est pas le cas. Si nous fusionnions une fonctionnalité à la fois, les risques de problèmes de régression sont plus grands. Ils ne sont détectés qu'une fois les fonctionnalités fusionnées en tant que maître et éventuellement en production.

Il doit y avoir un moyen de tester plusieurs fonctionnalités, de fusionner plusieurs fonctionnalités et de déployer les mêmes. J'utilise une "branche" (une branche créée à partir d'un maître avec des branches de fonctions de test prêtes à être fusionnées) qui est déployée sur qa / uat. Les corrections survenues pendant la durée de validité se produisent uniquement dans la branche de fonctionnalité et celles-ci sont fusionnées à nouveau avec la branche. Une fois qu'une sous-branche de la branche est approuvée, seules les fonctionnalités approuvées de l'ensemble sont demandées à maîtriser - et le cycle est continu.

J'utilise ceci avec Gitflow, mais je songe à l'utiliser pour le flux GitHub. Les nombreuses fonctionnalités QA / UAT à un moment donné paraissent importantes. Un autre problème avec le flux GitHub est qu’il suppose que tous les développeurs sont sûrs, et ce n’est pas toujours le cas.

Je préférerais utiliser le flux GitHub en raison de sa simplicité. Avec un paquet comme fonctionnalité, je pense que ce serait mieux prêt. Il est possible que le paquet ressemble à la publication. Cependant, je réfléchis encore à cela.

Un autre problème est que le processus de demande d'extraction se produit à la fin avant la fusion avec le maître; Cependant, vous souhaitez parfois revoir le code avant le test de qualité de service - donc bien avant la fusion.

David Latty
la source