web-dev-qa-db-fra.com

Brancher ou ne pas brancher?

Jusqu'à récemment, mon flux de travail de développement était le suivant:

  1. Obtenez la fonctionnalité du propriétaire du produit
  2. Créer une branche (si la fonctionnalité dure plus d'un jour)
  3. Implémentez-le dans une branche
  4. Fusionner les modifications de la branche principale vers ma branche (pour réduire les conflits lors de la fusion en amont)
  5. Fusionner ma branche vers la branche principale

Parfois, il y avait des problèmes de fusion, mais en général, j'aimais ça.

Mais récemment, je vois de plus en plus d'adeptes de l'idée de ne pas créer de succursales car cela rend plus difficile la pratique de l'intégration continue, de la livraison continue, etc. Et cela semble particulièrement drôle de la part de personnes ayant des antécédents VCS distribués qui parlaient tellement de grandes implémentations de fusion de Git, Mercurial, etc.

La question est donc de savoir si nous devons utiliser des succursales de nos jours?

continuous-integrationbranchingscm
86
SiberianGuy

À moins que vous ne travailliez tous à partir du même arbre de travail, vous êtes en utilisant des branches, que vous les appeliez ou non. Chaque fois qu'un développeur extrait son arbre de travail, il crée une branche de développement locale distincte et chaque fois qu'il s'enregistre, il fait une fusion. Pour la plupart des équipes, la question n'est pas si vous utilisez des branches, les questions sont combien et dans quel but?

La seule façon de réaliser une intégration vraiment "continue" est que tout le monde travaille à partir du même arbre de travail. De cette façon, vous savez immédiatement si vos changements ont un impact négatif sur quelqu'un d'autre. De toute évidence, c'est intenable. Vous avez besoin d'un certain degré d'isolement dans une branche pour accomplir quoi que ce soit, même si cette "branche" n'est que votre répertoire de travail local. Ce qu'il faut, c'est un bon équilibre d'intégration et d'isolement.

D'après mon expérience, utiliser plus de branches améliore le degré d'intégration, car l'intégration se fait précisément avec les personnes à effectuer, et tout le monde peut plus facilement isoler les problèmes non liés selon les besoins.

Par exemple, j'ai passé la dernière journée à rechercher trois bogues liés à l'intégration récemment introduits dans notre build qui bloquaient mon "vrai" travail. Ayant fait preuve de diligence raisonnable en signalant ces bogues aux personnes qui doivent les corriger, suis-je maintenant censé attendre jusqu'à ce qu'ils aient terminé pour continuer mon travail? Bien sûr que non. J'ai créé une branche locale temporaire qui annule ces modifications afin que je puisse avoir une base de référence stable sur laquelle travailler tout en recevant les dernières modifications en amont.

Sans la possibilité de créer une nouvelle branche à cet effet, je serais réduit à l'une des trois options: annuler les modifications dans le référentiel central, maintenir manuellement les correctifs qui les annulent dans mon arbre de travail et essayer de ne pas les archiver accidentellement , ou revenir à une version avant l'introduction de ces bogues. La première option est susceptible de briser une autre dépendance. La deuxième option demande beaucoup de travail, donc la plupart des gens choisissent la troisième option, ce qui vous empêche essentiellement de faire plus de travail d'intégration jusqu'à ce que les bogues trouvés précédemment soient corrigés.

Mon exemple a utilisé une branche locale privée, mais le même principe s'applique aux branches partagées. Si je partage ma branche, alors peut-être que 5 autres personnes pourront continuer leurs tâches principales au lieu d'effectuer un travail d'intégration redondant, donc un travail d'intégration plus utile est effectué. Le problème avec la création de branches et l'intégration continue n'est pas le nombre de branches que vous avez, mais la fréquence à laquelle vous les fusionnez.

64
Karl Bielefeldt

la question est de savoir si nous devons utiliser des succursales de nos jours?

Il y a environ un an et demi, j'ai été affecté à une étude pour répondre à cette question. Voici le résumé, basé sur les références étudiées (listées ci-dessous)

  • il n'y a pas de "meilleure" stratégie de branchement convenue pour tous les projets
    • la plupart des ressources semblent convenir que le choix d'une stratégie productive dépend des spécificités du projet
    • note de côté. Sur la base de ce qui précède, il semble que tout changement de stratégie de branchement de projet doive être testé, mesuré et comparé à d'autres options testées
  • l'opinion populaire est que la fusion avec Subversion demande beaucoup d'efforts. Tous ceux qui ont comparé SVN et Git notent que la fusion est extrêmement facile avec Git
  • un facteur important semble être de savoir si les rejets de production proviennent du tronc ou des branches. Les équipes qui produisent des versions de prod à partir du tronc (qui ne semblent pas tout à fait populaires) sont essentiellement interdites d'utiliser la stratégie tronc instable. Les équipes qui réalisent des versions de prod à partir de succursales ont plus d'options de ramification à choisir.
  • les stratégies populaires semblent être tronc stable, tronc instable et branche de développement (intégration)

références

  • http://msdn.Microsoft.com/en-us/library/aa730834%28v=vs.80%29.aspx

    ... Décider de la meilleure stratégie de branchement est un acte d'équilibre. Vous devez échanger les gains de productivité contre un risque accru. Une façon de valider une stratégie choisie est d'envisager un scénario de changement. Par exemple, si vous décidez d'aligner les branches avec l'architecture système (par exemple, une branche représente un composant système) et que vous vous attendez à des changements architecturaux importants, vous devrez peut-être restructurer vos branches et les processus et politiques associés à chaque changement. Le choix d'une stratégie de branchement inadéquate peut entraîner des frais généraux de processus et de longs cycles d'intégration et de publication qui s'avèrent frustrants pour toute l'équipe ...

  • http://www.cmcrossroads.com/bradapp/acme/branching/

    ... L'intégration progressive et fréquente est l'un des signes de réussite, et son absence est souvent une caractéristique de l'échec. Les méthodes actuelles de gestion de projet ont tendance à éviter les modèles stricts de cascade et à adopter les modèles en spirale du développement itératif/incrémental et de la livraison évolutive. Les stratégies d'intégration incrémentale, comme Merge Early and Often et ses variantes, sont une forme de gestion des risques qui tente d'éliminer les risques plus tôt dans le cycle de vie lorsqu'il y a plus de temps pour y répondre. La régularité du rythme entre les intégrations est considérée par [Booch], [McCarthy] et [McConnell] comme un indicateur avancé de la santé du projet (comme un "pouls" ou un "battement de cœur").

    Non seulement l'intégration précoce et fréquente étoffe le risque plus tôt et en "morceaux" plus petits, mais elle communique également les changements entre les coéquipiers ...

  • http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html

    ... Dans la plupart des systèmes de contrôle des sources, vous pouvez créer des centaines de branches sans aucun problème de performances; c'est le surcharge mentale de garder une trace de toutes les branches dont vous avez vraiment besoin de vous inquiéter ... La ramification est une bête complexe. Il existe des dizaines de façons de créer des succursales, et personne ne peut vraiment vous dire si vous le faites bien ou mal ...

  • http://www.lostechies.com/blogs/derickbailey/archive/2010/02/24/branching-strategies-when-to-branch-and-merge.aspx

    ... Il y a de nombreux aspects d'un système à prendre en compte lors du branchement de votre code ... En fin de compte, l'objectif est de fournir un bac à sable pour le contexte dans lequel le code est écrit. Comprendre les options disponibles, quand chaque option est la mieux adaptée à la situation actuelle et le coût de ces options vous aidera à décider comment et quand vous dériver ...

  • http://www.snuffybear.com/ucm_branch.htm
    Remarque étant donné les autres références répertoriées ici, la déclaration de l'auteur selon laquelle "Cet article décrit trois modèles de branchement clés utilisés dans les projets de génie logiciel" ne semble pas justifié. La terminologie utilisée ne semble pas répandue ( [~ # ~] efix [~ # ~], Model-1,2,3 etc).

  • http://svn.haxx.se/users/archive-2007-10/att-0101/SCMBranchingModels-talkback.pdf
    La référence présente un exemple intéressant de difficultés à communiquer les stratégies de branchement.

  • http://simpleprogrammer.com/2010/06/04/simple-branching-strategy-part-1-back-to-basics/
    ...Rester simple. Travailler directement sur le coffre est de loin la meilleure approche à mon avis.

    . vais vous montrer comment le faire fonctionner ...

    ... Si je devais fonder mon raisonnement sur un argument solide, ce serait la valeur de l'intégration continue. J'ai blogué sur le valeur de CI et meilleures pratiques dans le passé. Je suis un ardent défenseur de CI ...

    ... Vous devez vraiment vous poser une question ici: "Est-ce que tous les frais généraux que vous encourez en faisant votre stratégie de branchement et de fusion compliquée entraînent une valeur réelle qui n'existe pas par rapport à une stratégie plus simple?" ...

    ... Une stratégie que j'ai effectivement utilisée dans le passé et que j'ai développée au fil du temps. Je vais le résumer brièvement ici.

  • http://www.codelathe.com/blog/index.php/2009/07/02/a-svn-branching-strategy-that-works/
    ... Enfin, souvenez-vous qu'il n'y a pas de stratégie idéale de branchement et de fusion. Cela dépend à peu près de votre environnement de développement unique ...

  • http://blog.perforce.com/blog/?cat=62
    ... Le pire des cas est que vous introduisiez un problème de "fusion sémantique", où le résultat d'une fusion automatisée est incorrect, mais compile OK et se faufile après les tests, peut-être même survivant assez longtemps pour être un client -bogue visible. Eek!

    Ajoutant l'insulte à la blessure, car ils peuvent échapper à la détection plus longtemps, les problèmes de fusion sémantique sont plus difficiles à résoudre plus tard, car le changement n'est plus d'actualité dans l'esprit du développeur à l'origine du changement. (Il est généralement préférable de fusionner les modifications peu de temps après, idéalement par le développeur à l'origine du changement si cela est pratique) ...

  • https://stackoverflow.com/questions/34975/branching-strategies
    Les membres de la communauté partagent différentes expériences dans divers projets en utilisant différentes stratégies de branchement. Pas de consensus sur "le meilleur" ou "le pire".

  • http://www.stickyminds.com/s.asp?F=S16454_COL_2
    Essentiellement un bref résumé des éléments présentés dans http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

    • http://www.stickyminds.com/s.asp?F=S16511_COL_2
      ... Il existe trois approches courantes pour décider quand et comment créer une succursale:
      • Créez la branche de publication lorsque vous avez terminé la fonctionnalité et prévoyez de résoudre les problèmes de dernière minute sur cette ligne de code. Dans ce cas, la branche de publication est en réalité une "ligne de code de préparation de publication", comme décrit dans Modèles de gestion de la configuration logicielle , car vous vous attendez à ce qu'il y ait encore du travail à faire.
      • Modifiez votre style de travail pour éviter le travail d'intégration final, en dehors de la ligne de développement active.
      • Branche pour le nouveau travail en créant une branche de tâche et en fusionnant ce travail dans la ligne de développement active une fois la version terminée.
        ... Une justification de la ramification est d'isoler le code à la fin d'une version afin qu'il puisse se stabiliser. L'isolement par ramification masque souvent un problème de qualité qui finira par se manifester par le coût supplémentaire de la maintenance des flux parallèles avant la sortie d'un produit. La ramification est facile. C'est plutôt la fusion et la surcharge cognitive pour comprendre comment les changements se déroulent entre les branches qui sont difficiles, il est donc important de choisir un processus qui minimise le coût de la branche et de la fusion ...

  • http://nvie.com/posts/a-successful-git-branching-model/ Stratégie orientée Git.
    ... Nous considérons Origin/master comme la branche principale où le code source de HEAD reflète toujours une production -déjà état.

    Nous considérons Origin/develop comme la branche principale où le code source de HEAD reflète toujours un état avec les derniers changements de développement fournis pour la prochaine version. Certains appellent cela la "branche d'intégration". C'est là que toutes les versions nocturnes automatiques sont construites à partir de ....

  • http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html
    ... les politiques du projet varient considérablement concernant exactement quand il est approprié de créer une branche de fonctionnalité. Certains projets n'utilisent jamais du tout les branches de fonctionnalités: les commits à /trunk sont gratuits. L'avantage de ce système est qu'il est simple: personne n'a besoin de se renseigner sur la ramification ou la fusion. L'inconvénient est que le code de jonction est souvent instable ou inutilisable. D'autres projets utilisent des branches à l'extrême: aucun changement n'est jamais directement engagé dans le tronc. Même les changements les plus triviaux sont créés sur une branche de courte durée, soigneusement examinés et fusionnés dans le tronc. Ensuite, la branche est supprimée. Ce système garantit un tronc exceptionnellement stable et utilisable à tout moment, mais au prix de formidable surcharge de processus.

    La plupart des projets adoptent une approche intermédiaire. Ils insistent généralement pour que /trunk compile et passe des tests de régression à tout moment. Une branche de fonctionnalité n'est requise que lorsqu'une modification nécessite un grand nombre de validations déstabilisantes. Une bonne règle de base est de poser cette question: si le développeur travaillait pendant des jours de manière isolée puis commettait le grand changement d'un coup (de sorte que /trunk ne soit jamais déstabilisé), serait-ce un changement trop important à réviser? Si la réponse à cette question est "oui", la modification doit être développée sur une branche de fonctionnalité. Comme le développeur valide les modifications incrémentielles de la branche, elles peuvent être facilement examinées par les pairs.

    Enfin, il y a la question de savoir comment maintenir au mieux une branche de fonctionnalité en "synchronisation" avec le tronc à mesure que le travail progresse. Comme nous l'avons mentionné plus tôt, il y a un grand risque à travailler sur une succursale pendant des semaines ou des mois; les changements du tronc peuvent continuer à affluer, au point où les deux lignes de développement diffèrent tellement que cela peut devenir un cauchemar essayant de fusionner la branche vers le tronc.

    Il est préférable d'éviter cette situation en fusionnant régulièrement les modifications du tronc à la branche. Établissez une politique: une fois par semaine, fusionnez la valeur de la semaine dernière des changements de tronc à la branche ...

  • http://thedesignspace.net/MT2archives/000680.html
    ... Cette section du didacticiel Eclipse CVS est basée sur l'article de Paul Glezen sur le site Web Eclipse: Branching with Eclipse and CVS , et est utilisé avec sa permission selon les termes Licence EPL. Les changements que j'apporte à sa version sont principalement de l'étendre avec plus d'images et d'explications étape par étape, et de l'intégrer à mes propres tutoriels pour débutants afin de la rendre plus accessible aux débutants et aux concepteurs. Les développeurs expérimentés préféreront probablement travailler à partir de la version de Paul ...

  • http://learnsoftwareprocesses.com/2007/12/29/common-branching-strategies/
    ... Voici quelques-uns des modèles de branchement courants:

    1. Modèle de branche par version: L'une des stratégies de branche les plus courantes consiste à aligner les branches sur les versions de produit. Une branche détient tous les actifs de développement logiciel pour une seule version. Parfois, les mises à jour doivent être fusionnées d'une version à une autre, mais elles ne fusionnent généralement jamais. Les succursales seront fermées lorsqu'une version sera retirée.
    2. Branche par promotion: Une autre approche très courante consiste à aligner les succursales sur les niveaux de promotion des actifs logiciels. Une version de développement spécifique est dérivée dans une branche Test, dans laquelle tous les tests d'intégration et de système sont effectués. Une fois les tests terminés, les ressources de développement logiciel sont ramifiées dans la branche Production et finalement déployées.
    3. Branche par tâche: pour éviter le chevauchement des tâches (ou activités) et une perte de productivité, vous pouvez les isoler sur une branche distincte. Gardez à l'esprit que ce sont des branches à court terme qui doivent être fusionnées dès que la tâche est terminée, sinon l'effort de fusion requis pourrait dépasser les avantages de productivité de leur création en premier lieu.
    4. Branche par composant: vous pouvez aligner chaque branche sur l'architecture du système. Dans cette stratégie, vous dérivez des composants (ou sous-systèmes) individuels. Ensuite, chaque équipe développant un composant décide quand fusionner son code dans la ligne de développement qui sert de branche d'intégration. Cette stratégie peut bien fonctionner si l'architecture du système est en place et que les composants individuels ont des interfaces bien définies. Le fait que vous développiez des composants sur des branches permet un contrôle plus fin des ressources de développement logiciel.
    5. Branche par technologie: autre stratégie de ramification alignée sur l'architecture du système. Dans ce cas, les branches sont alignées sur les plateformes technologiques. Le code commun est géré sur une branche distincte. En raison de la nature unique des actifs de développement logiciel gérés sur les succursales, ils ne fusionnent probablement jamais ...

  • http://msdn.Microsoft.com/en-us/library/bb668955.aspx
    ... Reportez-vous aux directives de branchement et de fusion dans "Source Control Guidelines" dans ce guide pour un résumé des directives de branchement et de fusion. ... Lors du branchement, tenez compte des éléments suivants:

    • Ne branchez pas à moins que votre équipe de développement ait besoin de travailler simultanément sur le même ensemble de fichiers. Si vous n'êtes pas sûr de cela, vous pouvez étiqueter une génération et créer une branche à partir de cette génération ultérieurement. La fusion de branches peut être longue et complexe, surtout s'il y a des changements importants entre elles.
    • Structurez vos arborescences de branches de sorte que vous n'ayez besoin de fusionner que le long de la hiérarchie (de haut en bas de l'arborescence de branches) plutôt qu'à travers la hiérarchie. Le branchement à travers la hiérarchie nécessite que vous utilisiez une fusion sans base, qui nécessite une résolution plus manuelle des conflits.
    • La hiérarchie de branche est basée sur le parent de branche et l'enfant de branche, qui peuvent être différents de la structure physique du code source sur le disque. Lors de la planification de vos fusions, gardez à l'esprit la structure de branche logique plutôt que la structure physique sur le disque.
    • Ne branchez pas trop profondément. Parce qu'il faut du temps pour exécuter chaque fusion et résoudre les conflits, une structure de branchement profonde peut signifier que les changements dans une branche enfant peuvent prendre très longtemps pour se propager à la branche principale. Cela peut avoir un impact négatif sur les calendriers de projet et augmenter le temps de correction des bogues.
    • Branche à un niveau élevé et inclut la configuration et les fichiers source.
    • Faites évoluer votre structure de ramification au fil du temps.
    • La fusion nécessite un ou plusieurs développeurs pour exécuter la fusion et résoudre les conflits. La source fusionnée doit être minutieusement testée car il n'est pas rare de prendre de mauvaises décisions de fusion qui peuvent déstabiliser la génération.
    • La fusion dans la hiérarchie des succursales est particulièrement difficile et vous oblige à gérer manuellement de nombreux conflits qui pourraient autrement être gérés automatiquement.
      La décision de créer une succursale peut être réduite au fait que le coût de la fusion des conflits en temps réel est plus élevé que les frais généraux de la fusion des conflits entre les succursales ...

  • http://kashfarooq.wordpress.com/2009/11/23/Bazaar-branching-strategy-with-a-Subversion-trunk/

    • http://kashfarooq.wordpress.com/2010/12/16/Bazaar-branching-strategy-with-a-Subversion-trunk-revised/
    • http://kashfarooq.wordpress.com/2009/11/02/using-Bazaar-feature-branches-with-a-Subversion-trunk/
    • http://kashfarooq.wordpress.com/2009/09/08/Bazaar-or-git-moving-away-from-Subversion/
      ... Est-ce que l'une de ces plaintes Subversion vous semble familière?
      • Vous êtes informé au hasard que "vous devez exécuter la mise à jour". Vous effectuez ensuite une mise à jour - qui prend du temps à terminer. Et puis, enfin, vous voyez qu'il n'y avait aucun changement à télécharger.
      • Vous êtes informé au hasard que "vous devez exécuter le nettoyage".
      • Vous avez d'énormes problèmes de fusion. Par exemple, vous utilisez ReSharper pour renommer une classe, et d'autres ont mis à jour cette classe entre-temps. Vous voyez alors l'erreur de conflit d'arbre redouté (frisson). Ou pire encore, vous renommez un espace de noms et un dossier entiers (double frisson). Maintenant, vous êtes vraiment dans un monde de douleur.
      • Vos fusions ont tendance à être de plus en plus manuelles. Vous devez fréquemment utiliser WinMerge car Subversion n'a pas la moindre idée.
      • Vous attendez souvent que Tortoise mette à jour/vérifie les modifications/quoi que ce soit.

        J'ai un référentiel Subversion sur ma clé USB. J'obtiens des conflits d'arbre et je fusionne des problèmes avec ça, et je suis le seul utilisateur!

        Le principal problème est la fusion ...
    • "Subversion suce" semble familier. Il est temps d'écouter Joel et Linus ?

  • http://social.msdn.Microsoft.com/Forums/en/tfsversioncontrol/thread/f127676c-8f05-410c-9a30-0eb43a26a9fa
    discussion des meilleures pratiques pour la stratégie de branche d'isolement des versions dans le cas de systèmes en évolution.

  • http://branchingguidance.codeplex.com/
    "Microsoft Team Foundation Server Branching Guidance" - document énorme et détaillé avec des recommandations adaptées à différents projets: version HTML ici . Prouve que Microsoft ne croit pas en une approche universelle pour les stratégies de branchement.

  • https://stackoverflow.com/questions/597707/best-branching-strategy-when-doing-continuous-integration
    Quelle est la meilleure stratégie de branchement à utiliser lorsque vous souhaitez effectuer une intégration continue? ... La réponse dépend de la taille de votre équipe et de la qualité de votre contrôle de source et de la capacité de fusionner correctement des ensembles de modifications complexes ...

  • http://codicesoftware.blogspot.com/2010/03/branching-strategies.html
    ... CVS et SVN décourageaient toute la stratégie de branchement/fusion car ils étaient totalement incapables de le faire ... ... Règle simple: créez une branche de tâche pour chaque nouvelle fonctionnalité ou correction de bogue que vous devez mettre en œuvre ... Cela peut sembler exagéré pour les utilisateurs SVN/CVS mais vous savez que tout SCM moderne vous permettra de créer des branches en une seconde, donc il n'y a pas de réel surcoût.

    Remarque importante: si vous l'examinez attentivement, vous verrez que je parle d'utiliser des branches de tâches en tant que listes de modifications riches ...

  • http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_proj.doc/c_bntr_plnbrstrat.htm
    ... La politique de branchement est influencée par les objectifs de développement du projet et fournit un mécanisme pour contrôler l'évolution de la base de code. Il existe autant de variantes de stratégie de branchement que les organisations qui utilisent le contrôle de version de Rational ClearCase. Mais il existe également des similitudes qui reflètent l'adhésion commune aux meilleures pratiques ...

  • http://blogs.open.collab.net/svn/2007/11/branching-strat.html
    ... Le modèle Subversion (ou le modèle général open source plus précisément) est ce qui est montré dans le modèle de tronc instable ...

  • http://en.wikipedia.org/wiki/Trunk_%28software%29
    Dans le domaine du développement logiciel, trunk fait référence à la branche (version) d'une arborescence de fichiers sous contrôle de révision =. Le tronc est généralement destiné à être la base d'un projet sur lequel le développement progresse. Si les développeurs travaillent exclusivement sur le tronc, il contient toujours la dernière version de pointe du projet, mais peut donc également être la version la plus instable. Une autre approche consiste à séparer une branche du tronc, à implémenter des changements dans cette branche et à fusionner les changements dans le tronc lorsque la branche s'est avérée stable et fonctionne. Selon le mode de développement et la politique commit , le tronc peut contenir la version la plus stable ou la moins stable ou quelque chose entre les deux.

    Souvent, le travail principal du développeur a lieu dans le tronc et les versions stables sont ramifiées, et des corrections de bogues occasionnelles sont fusionnées des branches au tronc. Lorsque le développement de futures versions se fait dans des branches non-trunk, cela se fait généralement pour des projets qui ne changent pas souvent, ou où un changement devrait prendre beaucoup de temps à se développer jusqu'à ce qu'il soit prêt à être incorporé dans le tronc. .

  • http://www.mcqueeney.com/roller/page/tom/20060919
    ... Ce sont des notes d'un webinaire sur les meilleures pratiques de Subversion , organisé le 30 août 2006 par CollabNet. ... Deux stratégies organisationnelles: tronc instable vs tronc stable ... ... PRÉFÉRER un tronc instable lorsque c'est possible ...

  • https://stackoverflow.com/questions/153812/Subversion-is-trunk-really-the-best-place-for-the-main-development
    Dans SVN, le tronc est l'endroit recommandé pour le développement principal et j'utilise cette convention pour tous mes projets. Cependant, cela signifie que le tronc est parfois instable, voire cassé ... ... ne serait-il pas préférable de faire le "développement sauvage" sur une branche comme/branch/dev et de ne fusionner avec le tronc que lorsque la construction est raisonnablement solide?

    • ... Le tronc est l'endroit où le développement en cours est censé se produire. Vous ne devriez vraiment pas avoir de problème avec du code "cassé", si tout le monde teste ses modifications avant de les valider. Une bonne règle de base est de faire une mise à jour (obtenir tout le dernier code du référentiel) après avoir codé vos modifications. Ensuite, construisez et faites des tests unitaires. Si tout se construit et fonctionne, vous devriez être bon de le vérifier ...
    • ... Non, le coffre n'est pas le meilleur endroit. Dans notre organisation, nous suivons toujours cette approche: Trunk contient le code de version, donc il se compile toujours. Avec chaque nouvelle version/jalon, nous ouvrons une nouvelle branche. Chaque fois qu'un développeur possède un élément, il crée une nouvelle branche vers cette branche de version et la fusionne dans une branche de version uniquement après l'avoir testé. La branche Release est fusionnée dans le tronc après les tests du système ...

  • http://blog.yclian.com/2009/03/working-on-branches-and-stable-trunk.html
    ... J'avais l'habitude de travailler sur le coffre car pour tous les projets sur lesquels j'ai travaillé, c'est soit j'étais le seul développeur, soit l'équipe s'est assurée que tout le monde vérifiant le code a passé les tests locaux. Sinon, nous avons créé (nous avons toujours) des branches pour les corrections de bugs, un gros code pour les nouvelles fonctionnalités, etc.

    Il y a environ 2 mois, j'ai eu une courte session git avec Kamal et il a partagé avec moi l'idée de histoire/branche . Et comme mon équipe a commencé à grandir avec plus de gars de développement, je ressens le besoin d'encourager plus de branches et maintenant c'est devenu une règle. Pour un projet avec des tests automatisés définis avec la configuration CI, un tronc stable est garanti et cette pratique peut très bien s'y intégrer.

    Nous n'utilisons pas git mais Subversion parce que c'est comme ça que nous avons commencé et nous sommes toujours à l'aise avec ça maintenant (la plupart du temps) ...

  • http://www.ericsink.com/scm/scm_branches.html
    Cela fait partie d'un livre en ligne appelé Source Control HOWTO , un guide des meilleures pratiques sur le contrôle des sources, le contrôle des versions et la gestion de la configuration ...

    ... Pratique de branchement préférée d'Eric ... Gardez un coffre "fondamentalement instable". Faites votre développement actif dans le coffre, dont la stabilité augmente à l'approche de la sortie. Après avoir expédié, créez une branche de maintenance et gardez-la toujours très stable ...

    ... Dans le chapitre suivant je vais approfondir le sujet de la fusion des branches ...

  • http://marc.info/?l=forrest-dev&m=112504297928196&w=2
    Courrier de départ du fil de discussion sur les stratégies de branchement pour le projet Apache Forrest

    • notez actuellement que le projet semble utiliser un modèle de tronc instable avec des branches de version:
    • "Le travail de développement est effectué sur le tronc de SVN ... Il existe des" branches de publication "de SVN, par exemple forrest_07_branch." ( directives du projet )
    • "Création des packages candidats à la publication ... 17. Créez une branche de maintenance dans SVN ..." ( Comment publier )

  • Documents de branchement O'Reilly CVS:
    http://commons.oreilly.com/wiki/index.php/Essential_CVS/Using_CVS/Tagging_and_Branching#Basically_stable

    • ... La philosophie de branchement fondamentalement stable stipule que le tronc doit contenir des données de projet qui sont toujours sur le point d'être prêtes à être publiées ... tronc. Une telle approche détendue nécessite qu'un candidat à la version soit dérivé et soumis à une analyse QA complète avant la publication ...
    • ... La philosophie fondamentalement instable stipule que le tronc doit contenir le code le plus récent, quelle que soit sa stabilité, et que les versions candidates doivent être dérivées pour le contrôle qualité.


      ... Des variations plus clémentes permettent également de créer des branches pour le code expérimental, la refactorisation et d'autres codes spéciaux. La fusion d'une succursale dans le coffre est effectuée par les gestionnaires de la succursale. ...
      • La ressource ci-dessus n'apparaît dans aucune des recherches que j'ai effectuées (les directives relatives au CVS ne sont plus populaires?)

  • Meilleures pratiques dans SCM (article par force) sur
    http://www.perforce.com/perforce/papers/bestpractices.html
    ... six domaines généraux de déploiement SCM, et quelques meilleures pratiques à granularité grossière dans chacun de ces domaines. Les chapitres suivants expliquent chaque élément ...
    Espaces de travail, Codelines, Branchement, Propagation des modifications, Constructions, Processus ...

81
gnat

Si plusieurs équipes travaillent simultanément sur différentes fonctionnalités, il est impossible d'omettre la création de branches. Vous devez partager le code (partiellement implémenté) avec les membres de l'équipe, empêchant les autres équipes d'obtenir vos fonctionnalités non terminées.

Les succursales sont le moyen le plus simple d'y parvenir.

Bien qu'il soit bon de raccourcir le cycle de vie des branches et d'éviter de travailler sur le même module dans deux branches en même temps - vous n'aurez alors aucun problème de conflit\fusion.

7
Shaddix

Mais récemment, je vois de plus en plus d'adeptes de l'idée de ne pas créer de succursales car cela rend plus difficile la pratique de l'intégration continue, de la livraison continue, etc.

Est-ce que cela rend plus difficile la pratique de l'intégration continue, de la livraison continue, etc pour vous concrètement?

Sinon, je ne vois aucune raison de changer votre façon de travailler.

Bien sûr, c'est une bonne pratique de suivre ce qui se passe et comment les meilleures pratiques actuelles évoluent. Mais je ne pense pas que nous devions abandonner nos processus/outils/ainsi de suite simplement parce que X (et/ou Y et/ou Z) ont dit qu'ils ne sont plus à la mode :-)

5
Péter Török

Quel intéressant ensemble de réponses. Depuis plus de 20 ans, je n'ai jamais travaillé dans une entreprise qui faisait plus qu'un usage trivial de la branche (généralement juste pour créer des branches).

La plupart des endroits où j'ai travaillé s'appuient sur des enregistrements assez rapides et une détection/résolution rapide des collisions - La méthodologie agile enseigne que vous pouvez résoudre les problèmes plus rapidement si vous les remarquez pendant que les deux parties réfléchissent activement à ce morceau de code.

D'un autre côté, je n'ai pas beaucoup utilisé git et c'est peut-être l'inclusion de la balise git qui a influencé ces réponses - je comprends que la branche/fusion est une donnée avec git parce que c'est si facile.

4
Bill K

Oui, vous devez utiliser des branches pour isoler tout effort de développement (au moins moyen). Voir " Quand devriez-vous créer une branche? ".

Le problème est plus d'utiliser des fusions rapides (qui incluent un historique de branche dans un autre), à ​​condition que vous écrasiez d'abord tous les "validations de points de contrôle intermédiaires" (qui peuvent être un problème en cas de restauration ou git bisect).
Voir " nderstanding Git workflow ", afin de distinguer les branches privées (non destinées à être poussées) des branches publiques, qui seront complétées par des fusions ff (fusion rapide) fournies que vous effectuez le nettoyage nécessaire dans la branche que vous fusionnez.
Voir aussi " Pourquoi git utilise la fusion rapide par défaut? ".

3
VonC

Nous venons de traverser cette (encore) .. Tout d'abord, nous avons eu tout le débat GIT/SVN, ce qui nous a conduit à des stratégies de branchement en général.

Les grandes entreprises utilisent toutes une stratégie basée sur le tronc, où tout le monde travaille dans la même branche, et les builds et l'intégration continue se produisent à partir de cette branche. Pour éviter les conflits, utilisez la modularisation du code, la commutation des fonctionnalités et les outils intelligents. Cela semble difficile .. parce que ça l'est. Mais si vous avez ce débat, c'est parce que vous avez été victime des fantasmes des gens sur la ramification. Certains prétendent qu'ils utilisent insérer l'outil SCM ici avec un mécanisme de branchement de promotion entièrement conforme à sarbanes-oxley, et c'est tout brillant. Ils mentent, se trompent ou ne travaillent pas sur la même échelle de système que vous.

La ramification et la fusion sont difficiles. Surtout si vous avez une entreprise qui change régulièrement d'avis et qui demande des annulations, etc.

Cette phrase peut vous sauver la vie: Ce qui est dans le SCM n'est pas le même que ce qui est dans vos artefacts construits!

Si vous rencontrez des problèmes de branchement, c'est parce que vous utilisez votre SCM à mauvais escient. Nous le faisons tous depuis des années. Vous avez un système en place où le SCM est utilisé pour déterminer ce qui va dans votre version finale.

Ce n'est pas le travail du SCM. Le SCM est un serveur de fichiers glorifié. Le travail de détermination des fichiers de votre SCM qui entrent dans votre build appartient à votre outillage de build.

Le module A est en cours d'élaboration et va dans votre version hebdomadaire. Le module B est le module A mais avec le projet X dedans, et il est en cours de travail, dans la même branche, mais n'est pas intégré à votre version. À un moment donné, vous souhaitez publier le projet X. Vous dites donc à votre outil de génération de cesser de mettre le module A et de commencer à mettre le module B.

Il y aura beaucoup de pleurer et de se tordre les mains à ce sujet. Quel sifflement et hurlement général. Tel est le niveau d'émotion entourant quelque chose d'aussi simple qu'un référentiel de fichiers, aussi intelligent soit-il.

Mais il y a votre réponse.

2
Richard

Vous devez absolument utiliser des branches. Il y a plusieurs points forts à cela.

  • Vous pouvez enregistrer votre travail au fur et à mesure si vous craignez de perdre du travail en raison d'une panne HD, d'une perte d'ordinateur portable, etc. et cela ne cassera pas le CI principal.
  • Vous pouvez toujours faire du CI, il vous suffit de configurer votre propre CI local pour surveiller votre branche.
  • Si la fonction est soudainement mise en attente (ce qui n'arrive jamais), vous pouvez simplement la garer.

Trop dur n'est jamais une excuse. Il faut toujours plus d'efforts pour bien faire les choses.

2
Bill Leeper

Si deux équipes travaillent sur leur propre branche, elles ne verront pas les changements de l'autre équipe, même si les deux intègrent la branche master. Cela signifierait que leurs branches de développement s'éloigneront et si l'une des équipes fusionne avec master, l'autre équipe doit rebaser de nombreux changements.

Donc, même si vous avez des branches pour les fonctionnalités, je vous exhorte à faire des "rétroportages" de tous les refactorings vers la branche principale et à ne conserver la branche que pour les nouvelles fonctionnalités.

  • Refonte du backport

Je pense que parfois, il pourrait être plus facile d'utiliser des commutateurs de fonctionnalités pour désactiver de nouvelles fonctionnalités non testées qui ne devraient pas encore entrer en production. De cette façon, toutes les autres équipes verront les changements et aucune fusion big bang n'aura lieu.

  • Utiliser des commutateurs de fonctionnalités
2
flob

Le principal problème avec la ramification est la difficulté de fusionner avec la branche principale lorsque le développement est terminé. La fusion peut être un processus manuel et sujet aux erreurs, elle doit donc être évitée la plupart du temps.

Certaines exceptions notables où je préfère la ramification concernent le refactoring massif, les fonctionnalités géantes qui prennent plus de temps qu'un sprint à développer, ou les fonctionnalités perturbatrices qui interrompront le développement d'autres fonctionnalités pendant la majorité de ce sprint.

1
maple_shaft

Je recommande ce type de schéma de branche:

release - test - développement

Puis du développement, branche par développeur et/ou par fonctionnalité.

Les développeurs ont chacun une branche avec laquelle ils peuvent jouer et fusionner, puis dans la branche de développement régulièrement - idéalement tous les jours (à condition qu'elle se compile).

Ce type de schéma fonctionne très bien avec de nombreux développeurs et plusieurs projets sur la même base de code.

1
Paul Nathan

Le processus dans mon organisation utilise largement les branches et (un processus qui ressemble un peu) à une intégration continue.

À un niveau élevé, les développeurs ne se soucient pas trop de la fusion avec la ligne principale, ils s'engagent simplement dans la branche. un processus (semi-) automatisé vérifie quelles fonctionnalités doivent entrer dans la ligne principale, fusionne ces branches et construit le produit. Le processus fonctionne car nous intégrons réellement ce processus de fusion à partir du suivi des problèmes, de sorte que l'outil de génération sache quelles branches fusionner.

0
SingleNegationElimination

Nous faisons utilisons des branches, mais pas au niveau granulaire de la fonctionnalité. Nous utilisons des branches pour chaque sprint. La création de branches n'est pas une mauvaise chose IMO, car elle simule le concept de SOC dans la fonctionnalité ou la couche de sprint. Vous pouvez facilement reconnaître et gérer quelle branche appartient à quelle fonction ou sprint.

À mon humble avis, alors la réponse est, OUI . Nous devons toujours utiliser la ramification.

0
Saeed Neamati