Stratégies De Branchement

Question

La société pour laquelle je travaille est de commencer à avoir des problèmes avec leurs branches et je me demandais quels sont les différents types de stratégies de branchement de la communauté a été exposé?

Existe-il des bons pour des situations différentes? Que fait votre entreprise? Quels sont les avantages et les inconvénients d'eux??

Answer 1

Voici la méthode que j'ai utilisé dans le passé avec succès:

/coffre - bord de saignement. La prochaine version majeure du code. Peut ou peut ne pas fonctionner à un moment donné.

/branches/1.0, 1.1, etc. Stable les branches de maintenance du code. Utilisé pour corriger les bugs, de stabiliser les nouvelles versions. Si une branche de maintenance, il doit compiler (le cas échéant) et être prêt pour l'AQ/expédition, à un moment donné. Si une stabilisation de la branche, il doit compiler et d'être complète. Pas de nouvelles fonctionnalités devraient être ajoutés, pas de refactoring, et pas de code de nettoyage. Vous pouvez ajouter un pré - préfixe pour indiquer la stabilisation des branches vs les branches de maintenance.

/branches/cool_feature. Utilisé pour les projets expérimentaux ou destructeur de travail qui peut ou ne peut pas le faire dans le coffre (ou une branche de maintenance). Aucune garantie au sujet de code de la compilation, de travail, ou au contraire de se comporter sainement. Devrait durer un minimum de temps possible avant de les fusionner dans la canalisation principale de la branche.

/tags/1.0.1, 1.0.2, 1.1.3, etc. Utilisé pour le marquage d'un emballés et expédiés libération. Jamais ne change JAMAIS. Faire autant de tags que vous voulez, mais ils sont immuables.

Answer 2

J'avais fortement encourager la lecture et Eric du récepteur d'avis sur la question:

Chapitre 7: Les Branches

J'ai, comme Eric, préférez le "dossier" style de branchement qui il parle.

Answer 3

Pour le filon-mère sur les modèles de ramification voir Brad Appleton Diffusé des Lignes de: Modèles de Ramification Parallèle le Développement de Logiciels. C'est lourd mais je n'ai rien vu à surpasser en termes de largeur et de la profondeur de la connaissance sur la branche.

Answer 4

Notre référentiel ressemble:

/trunk
/branches
/sandbox
/vendor
/ccnet

/trunk est votre norme, à la pointe du développement. Nous utilisons CI donc, ce doit toujours construire et à passer les examens.

/branches c'est là que nous avons mis 'sanctionné" grands changements, c'est à dire quelque chose, nous le SAVONS, dans le tronc, mais peut nécessiter un peu de travail et se briser CI. Aussi où nous travaillons sur des versions de maintenance, qui ont leurs propres projets d'ac.

/sandbox chaque développeur dispose de son propre bac à sable, plus partagée bac à sable. C'est pour des choses comme "vous Permet d'ajouter un fournisseur LINQ pour notre produit", le type de tâches que vous pouvez faire lorsque vous ne faites pas votre travail réel. Il peut éventuellement aller dans le tronc, il ne peut pas, mais il est là et sous le contrôle de version. Pas de CI, de là.

/vendor standard du vendeur direction pour les projets où nous compiler mais il n'est pas le code que nous maintenons.

/ccnet c'est notre IC balises, seul le serveur CI peut l'écrire ici. Le recul serait nous ont dit de le renommer en quelque chose de plus générique comme CI, constructions, etc.

Answer 5

1. Une branche pour le développement actif (/main de maître, selon le jargon)
2. Une branche pour chaque version de maintenance -> il ne recevra que vraiment petites corrections, tandis que tous les grands de développement va à l' /main
3. Une branche pour chaque nouvelle tâche: créer une nouvelle branche de travailler sur chaque nouvelle entrée sur votre Bugzilla/Jira/Rallye. Commettre souvent, auto document le changement à l'aide du pouce de galets archivages, et fusionner de nouveau à son "parent" branche seulement quand c'est fini et bien testé.

Jetez un oeil à ce http://codicesoftware.blogspot.com/2010/03/branching-strategies.html pour une meilleure explication