Différentes approches du branchement de contrôle de source

Question

Lors de l'utilisation du contrôle de source, la façon dont je suis habitué à travailler est de développer sur le tronc, puis de brancher le tronc juste avant de passer au contrôle qualité. Je parlais avec d'autres personnes du ministère et apparemment, il y a des points de vue passionnés au sujet d'une façon différente de travailler, qui serait de créer la nouvelle succursale au tout début du cycle de développement, de faire des travaux de développement là-dessus. branchez, puis fusionnez-le au tronc à la fin. L'idée sur cette approche est de garder le tronc vierge. Bien que je sois très sceptique quant à la prétention que l'un des promoteurs a fait de cette approche une approche «standard» (même si je suis heureux d'apprendre autrement), je ne serais pas surpris d'entendre que c'est assez commun. Je peux imaginer quelques avantages (plus facile à choisir quand déployer quelle fonctionnalité ou ensemble de fonctionnalités) mais aussi quelques inconvénients (problèmes de fusion potentiels puisque chaque branche doit être fusionnée avec le tronc).

fait des recherches ultérieures et trouvé ceci: http://www.lostechies.com/blogs/derickbailey/archive/2009/07/15/branch-per-feature-source-control-introduction.aspx

serait curieux d'entendre des gens leur sens pour les forces et les faiblesses de ces approches, et aussi sur toute autre approche que les gens peuvent utiliser.

Answer 1

C'est une question très similaire à ce précédent article SO:

Subversion - should anyone be developing off the trunk?

Pas exactement identique, mais beaucoup des concepts dans les réponses sont les mêmes.

Mon opinion personnelle? Le tronc est pour le développement actif; Les lignes de développement des anciennes versions que vous voulez garder "vierge" devraient être conservées dans les branches de la version (et les balises pour les versions). Vous pouvez toujours essayer de maintenir une maxime "le tronc devrait toujours compiler" même avec le développement actif sur le tronc.

Answer 2

Avec une équipe travaillant sur la même chose, c'est une bonne approche pour travailler dans le coffre, et créer une branche avant la sortie. Vous minimisez l'enfer de fusion, et vous avez une branche distincte pour chaque version si vous devez faire un correctif, ou revenir pour une raison quelconque. Mais, lorsque vous travaillez avec plusieurs équipes qui font des choses différentes, cela ne fonctionnera pas car elles vont certainement entrer en collision dans le coffre. Je n'ai pas beaucoup d'expérience à ce sujet, donc j'attends avec impatience quelques idées à ce sujet. Une approche serait d'avoir plusieurs branches, une pour chaque équipe peut-être, puis de fusionner les branches qui vont dans la version dans le coffre. (Je peux seulement imaginer la frustration) :)

Answer 3

Je préfère garder le coffre propre. Cela permet de compiler une version de travail à tout moment, pour libérer un correctif, une version bêta, créer une version démo ...

Les modifications sont effectuées sur des branches séparées. Cela donne une meilleure traçabilité, et on peut profiter du contrôle de la source sur la branche et vérifier les versions intermédiaires. Dans un monde idéal, les problèmes de fusion sont couverts par des tests [automatiques]. Le plus tôt vous intégrez les changements dans le coffre, mieux c'est. Ne placez pas de code non testé sur le tronc car cela finira par ralentir quelqu'un.