Existe-t-il des défauts avec ce modèle de branchement Git?

Je pose des questions sur ce modèle de branchement git ou ce flux de travail. J'aime vraiment ça. Cela me semble très intuitif et productif, mais ce que je demande, c'est s'il y a des défauts ou des négatifs dans cette approche qui ne sont pas encore clairs pour moi (venant d'un autre monde où ClearCase a régné la journée).

(Vous n'avez pas besoin de répondre à toutes les questions, tout ce que vous pouvez est utile)

1. Utilisez-vous ceci ou un workflow de branchement git similaire?

2. Considérez-vous cela comme une approche productive?

3. Voyez-vous des défauts avec cette approche? Un inconvénient potentiel?

4. Si vous avez une meilleure approche, pourriez-vous partager ou fournir un lien vers un article ou une discussion à ce sujet?

Pour la plupart, c'est le flux de travail habituel utilisé avec n'importe quel VCS que nous avons utilisé jusqu'à présent. Avec certains (CVS, SVN) c'est plus difficile à faire, avec GIT c'est trivial. Cela dit, j'ai deux remarques:

Premièrement, il existe deux écoles de pensée en ce qui concerne les branches:

1. Fusionnez-les
2. Les rebaser

(1) est ce que l'article semble suggérer. Le problème avec les validations de fusion est ce que l'on appelle les Evil Merges . Plus précisément, ceux qui rejoignent les chemins de développement où une fonction a changé la sémantique dans l'une des branches, mais la fusion automatique ne parvient pas à corriger toutes les occurrences du code provenant de l'autre branche. Les régressions introduites de cette façon sont notoirement difficiles à déboguer. En tant qu'utilisateur GIT, vous pouvez généralement être beaucoup plus détendu à propos des régressions, car vous devez git bisecttrouver automatiquement leurs causes. Cependant, dans la situation décrite, git bisectindiquera le commit de fusion, ce qui ne vous aide pas du tout.

(2) évite ce problème en essayant de maintenir une histoire aussi linéaire que possible. Ces rebases opposés prétendent que cela invalide tout test que vous avez pu faire avant le rebase.

Personnellement, je suis fermement dans le camp (2), car j'apprécie git bisectdavantage la validité des résultats que la perte potentielle de la couverture de test, qui est facilement compensée en utilisant un système d'IC ​​approprié.

Deuxièmement, j'ai décidé pour moi que pousser entre développeurs est rarement une bonne idée. Il y a des problèmes de sécurité impliqués dans le fait de permettre à tout le monde de ssh dans votre boîte de chercher, ou d'exécuter git-deamon localement, et, plus important encore, dans les équipes pas extrêmement petites, la surveillance peut se perdre assez rapidement.

Cela dit, je suis tout à fait en faveur d'un référentiel intermédiaire (parfois aussi appelé scratch ), qui permet aux sous-équipes de partager leur travail en cours via un serveur central qui est cependant différent du serveur principal (souvent vers l'extérieur). face, sinon publique). En règle générale, chaque sous-équipe conserve une branche de sujet pour elle-même, et un système CI effectue des fusions de poulpe périodiques de toutes les branches de sujet en une grande branche d'intégration, se plaignant des conflits et des erreurs de génération.

Je suis actuellement en train de procéder à des refactorisations massives et de longue date (conversion d'une application de l'une à l'autre boîte à outils GUI) et d'effectuer un workflow centré sur le rebase, car les autres membres de l'équipe continuent de travailler sur de nouvelles fonctionnalités:

Il existe principalement deux branches principales, la masteroù les nouvelles fonctionnalités sont développées et la toolkit-conversionbranche. La règle la plus importante est simple: ne faites que des choses dans la toolkit-conversionbranche qui sont pertinentes pour la conversion. Chaque fois qu'il y a quelque chose qui peut être fait dans master(l'ancienne boîte à outils de l'interface graphique), je le fais là et je rebase mes toolkit-conversionmodifications vers la nouvelle mastertête. Une autre règle consiste à garder la toolkit-conversionbranche assez courte. Par conséquent, j'utilise souvent reset, cherry-pick et amend-commit et rebase pour coller les plus petits commits aux plus grands (qui à la fin ont le même but). Cela fonctionne également très bien lorsque j'ai essayé quelque chose qui n'a pas bien fonctionné pour «annuler» la modification ou après avoir refactorisé du code avec du code d'assistance temporaire.

J'ai décidé de ne pas fusionner les modifications de masterdans toolkit-conversionbranche, car il serait beaucoup plus difficile de rebaser les commits précédents pour garder la branche propre et facile à réviser. En outre, les fusions peuvent introduire des conflits dont les résolutions ne sont pas aussi claires que lors du maintien d'une histoire propre.

Bien sûr, ce flux de travail présente également des inconvénients. Le plus important est qu'il ne fonctionne bien que pour une seule personne. Chaque fois que je force la poussée de la toolkit-conversionbranche après l'avoir rebasée vers la tête de master, la tirer sur un autre référentiel devient difficile (le rebasage automatique sur la branche de suivi échoue souvent avec les conflits).

Au final, ma toolkit-conversionbranche reste courte, propre et facile à revoir. Je ne pouvais pas imaginer avoir fait ce même puissant avec, par exemple, SVN.

Dans l'entreprise dans laquelle je travaille actuellement, nous appliquons une variante de ce même modèle de branchement depuis un certain temps. Nous avons également utilisé Scrum afin de créer une branche par flux de travail.

Le seul problème que nous ayons rencontré jusqu'à présent est lorsque l'équipe est suffisamment grande et que plus d'une histoire peut être démarrée et que ces histoires dépendent les unes des autres, cela devient une sorte de gâchis de fusionner les changements entre les branches et de revenir au maître.

En plus de cela, cela s'est avéré fiable :).

Je suis actuellement occupé à adapter ce flux de travail. Je pense que c'est un assez bon workflow, car il utilise le modèle de branchement dans lequel git excelle.

Le seul petit inconvénient est qu'il faut une certaine discipline pour se tenir à ce flux de travail et ne pas essayer de prendre des raccourcis.

Les développeurs de kohana utilisent également ce flux de travail, et ils semblent l'aimer beaucoup.

Utilisez-vous ceci ou un workflow de branchement git similaire?

Nous utilisons un workflow similaire au travail, mais un peu moins compliqué. Il est cependant grandement inspiré par ce workflow, puisque j'ai lu cet article plusieurs fois. J'ai même le pdf du modèle de branchement imprimé en couleurs à côté de mon bureau :)

Considérez-vous cela comme une approche productive?

Productif. Comment définissez-vous la productivité? Eh bien, dans mon esprit, il est très important d'avoir une qualité élevée, au moins pour essayer d'obtenir une meilleure qualité tout le temps. Améliorer constamment le processus, etc. Si vous pouvez produire un code de qualité, la productivité en bénéficiera. La question est donc vraiment: cela améliore-t-il la qualité du logiciel? Et ma réponse est définitivement oui.

Ce que j'aime le plus avec ce type de modèle de branchement, c'est qu'il introduit des branches dans différentes couches de qualité. Plus l'image est à droite, plus la stabilité et la qualité sont élevées. La branche maître est sainte et tous les engagements doivent être considérés comme des versions stables du logiciel. Plus vous allez vers la gauche, plus expérimental et plus la stabilité est faible.

Dès que vous testez de nouvelles fonctionnalités et corrections de bogues, vous pouvez les transférer progressivement de gauche à droite et ainsi vous déplacer dans du code de haute qualité exactement lorsque vous savez que le code répond aux exigences de qualité que vous exigez du code. Eh bien, au moins en théorie, car vous ne pouvez pas tout tester à 100% et sachez avec certitude que le code ne contient aucun bogue, car il aura toujours des bogues. Mais cela vous permet de garder une confiance élevée.

En tant que programmeur, rien n'est plus nul que de travailler dans un système où personne n'a confiance dans le code, car ils savent qu'il est nul et qu'il contient une merde de bogues.

Voyez-vous des défauts avec cette approche? Un inconvénient potentiel?

Il est important de réfléchir à votre modèle de branchement afin qu'il corresponde bien aux besoins de votre organisation. Le fait que ce modèle fonctionne bien pour certaines personnes ne signifie pas nécessairement qu'il est optimal ou souhaitable pour une autre.

Il y a toujours des compromis et même dans ce cas. Un compromis est le nombre de branches par rapport à la complexité. En introduisant de nombreux types de branches différents, vous augmentez la complexité du flux de travail. Par exemple, il peut être tout simplement faux de forcer toujours les gens à créer une nouvelle branche de fonctionnalité, lorsqu'ils essaient de corriger un simple bogue en modifiant quelques lignes de code.

Nous savons tous que les bugs sont plus ou moins compliqués à résoudre. Ainsi, lorsqu'un bug trivial est découvert, vous voudrez peut-être réduire la complexité et l'administration pour vous débarrasser de la surcharge supplémentaire et laisser les gens s'engager directement par exemple dans le master ou développer la branche. Mais comme la nature de vos correctifs devient plus compliquée, cela vaut la peine de surcharger pour leur créer de nouvelles branches. Surtout si vous n'êtes pas sûr de sa taille et de sa longueur ou si vous souhaitez améliorer la collaboration entre vous et les autres développeurs.

Si vous avez une meilleure approche, pourriez-vous partager ou fournir un lien vers un article ou une discussion à ce sujet?

Il s'agit sans aucun doute d'une bonne approche et elle pourrait convenir à la plupart des cas, car la plupart d'entre nous ont des processus de développement similaires, mais elle pourrait ne pas convenir à tout le monde. Je vous invite fortement à réfléchir à la façon dont vous gérez votre code en ce moment et à essayer de créer un modèle de branchement qui correspond à celui que vous avez déjà.

Le point le plus important est de commencer avec git et le reste suivra naturellement. Commencez simplement et améliorez progressivement! Sois créatif!

À votre santé