Quand devriez-vous créer une succursale?
Lorsque vous travaillez avec un système SCM, quand devez-vous créer une succursale?
Il existe plusieurs utilisations pour la ramification. L'une des utilisations les plus courantes consiste à séparer les projets qui avaient autrefois une base de code commune. C'est très utile pour expérimenter avec votre code, sans affecter le tronc principal.
En général, vous verriez deux types de branche:
Branche de fonctionnalités: si une fonctionnalité particulière est suffisamment perturbatrice pour que vous ne souhaitiez pas que toute l'équipe de développement soit affectée à ses débuts, vous pouvez créer une branche sur laquelle effectuer ce travail.
Branche de correctifs: Pendant que le développement se poursuit sur le tronc principal, une branche de correctifs peut être créée pour conserver les correctifs vers la dernière version publiée du logiciel.
Vous pouvez être intéressé par la lecture de l'article suivant, qui explique les principes de branchement et quand les utiliser:
En termes généraux, l'objectif principal de la ramification (une fonction VCS - Version Control System -) est de réaliser l'isolement du code .
Vous avez au moins une branche une, qui peut être suffisante pour le développement séquentiel, et est utilisée pour de nombreuses tâches enregistrées (validées) sur cette même branche unique.
Mais ce modèle montre rapidement sa limite:
Lorsque vous avez un effort de développement (refactoring, évolution, correction de bugs, ...) et que vous réalisez que vous ne pouvez pas effectuer ces modifications en toute sécurité dans la même branche que votre branche de développement actuelle (car vous briseriez l'API ou introduiriez du code qui briserait) tout), alors vous avez besoin d'une branche une autre.
(Pour isoler ce nouveau code pour l'ancien, même si les deux jeux de codes seront fusionnés plus tard)
Voilà donc votre réponse ici:
Vous devez créer une branche chaque fois que vous ne pouvez pas poursuivre et enregistrer deux efforts de développement dans une branche.
(sans avoir une histoire horriblement compliquée à maintenir).
Une branche peut être utile même si vous êtes le seul à travailler sur le code source, si vous êtes nombreux.
Mais vous ne devez pas créer "une seule branche par développeur":
le but de "l'isolement" est fait pour isoler un effort de développement (une tâche qui peut être aussi général que "développons la prochaine version de notre logiciel" ou aussi spécifique que "corrigeons le bug 23"),
pour ne pas isoler une "ressource" .
(une branche appelée "VonC" ne signifie rien pour un autre développeur: que se passe-t-il si "VonC" quitte le projet? Qu'est-ce que vous êtes censé en faire?
une branche appelée "bugfix_212" peut être interprétée dans le contexte d'un système de suivi des bogues par exemple, et tout développeur peut l'utiliser avec au moins une idée de ce qu'il est censé en faire)
Une branche n'est pas une balise (SVN est un Revision System qui essaie de proposer une fonction de versioning s comme le branchement et le balisage dans des répertoires avec une copie de fichier bon marché: cela ne signifie pas qu'une balise est une branche
Définir une branche signifie également définir un workflow de fusion : vous devez savoir où fusionner votre branche lorsque vous avez terminé avec il.
Pour cela, le chapitre 7 de Practical Perforce (Laura WINGERD - O'Reilly) est une bonne introduction (agnostique VCS) pour fusionner le workflow entre différents types de branches: "" Comment évolue le logiciel "(pdf)
Il définit le terme codeline (branche qui enregistre les étapes d'évolution significatives du code, soit par des balises à certains points, soit par une fusion importante vers la branche)
Il présente le modèle principal (une ligne de code centrale pour enregistrer les versions) et décrit divers objectifs de branchement:
- Flux de développement actifs : une ligne de code persistante lors de divers développements séquentiels
- branches de tâches : branches de courte durée pour des tâches plus spécifiques (la correction de bogues est classique, mais vous pouvez également définir une branche pour un effort de fusion que vous savoir être complexe à terminer: vous pouvez fusionner, valider et tester dans cette branche de tâche sans introduire de problème pour la principale branche de développement actuelle)
- branche intermédiaire : pour préparer une version, avec des données spécifiques à la pré-production ou des fichiers de configuration.
- Branches privées, branches ad hoc et branches clairsemées : pour les très petites tâches, juste pour pouvoir engager un travail en cours sans attendre la fin formelle ou examen du test.
Cela permet de "s'engager tôt, engager souvent".
Autres concepts intéressants autour de VCS: Concepts de base
(à propos de ClearCase à l'origine, mais également valable pour tout VCS)
Tous les SCM du 21ème siècle vous disent:
Branche pour chaque tâche sur laquelle vous devez travailler , qu'il s'agisse d'une nouvelle fonctionnalité, d'une correction de bogue, d'un test, peu importe. C'est ce qu'on appelle la branche de rubrique, et cela change la façon dont vous travaillez avec votre SCM.
Vous recevez:
- Meilleure isolation
- Meilleure traçabilité -> vous associez des tâches à des branches et non à des ensembles de modifications individuels, ce qui vous permet de vous engager autant de fois que vous le souhaitez et n'impose pas de limite comme "un enregistrement par tâche".
- Les tâches sont indépendantes (normalement à partir d'une ligne de base stable, donc vous vous concentrez uniquement sur votre code, pas sur la correction des bogues de vos contacts), et vous pouvez choisir si vous souhaitez les intégrer à un moment donné ou plus tard, mais elles sont toujours sous contrôle de version
- Vous pouvez revoir le code facilement (à partir du contrôle de version, pas de conneries pré-validées) avant de frapper la ligne principale
Des outils qui peuvent le faire:
Des outils qui NE PEUVENT PAS le faire:
- SVN
- CVS
- VSS
- TFS
- Perforce
Cela dépend également de l'outil SCM que vous utilisez. Les SCM modernes (git, Mercurial, etc.) facilitent de plus en plus la création et la destruction de branches à tout moment. Cela vous permet, par exemple, de créer une branche par bogue sur lequel vous travaillez. Une fois que vous avez fusionné vos résultats dans le tronc, vous jetez la branche.
D'autres SCM, par exemple Subversion et CVS, ont un paradigme de branchement beaucoup plus "lourd". Cela signifie qu'une branche n'est considérée comme appropriée que pour quelque chose de plus grand qu'un patch de vingt-quelque chose. Là, les branches sont classiquement utilisées pour suivre des pistes de développement entières, comme une version de produit précédente ou future.
Lorsque vous devez apporter des modifications importantes et/ou expérimentales à votre base de code, en particulier si vous souhaitez valider des modifications intermédiaires, sans affecter le tronc.
Cela dépend du type de SCM que vous utilisez.
Dans les versions distribuées plus récentes (comme git et Mercurial), vous créez des branches tout le temps et vous réémettez de toute façon. Je vais souvent travailler sur une branche distincte pendant un certain temps simplement parce que quelqu'un a rompu la construction sur la ligne principale, ou parce que le réseau est en panne, puis fusionner les modifications plus tard lorsqu'il est résolu, et c'est si facile à faire que ce n'est même pas ennuyeux .
Le document (court et lisible) qui m'a le plus aidé à comprendre ce qui se passait dans les systèmes distribués est: nderstandingMercurial .
Dans les anciens systèmes avec un référentiel central, (comme CVS, SVN et ClearCase), alors c'est un problème beaucoup plus grave qui doit être décidé au niveau de l'équipe, et la réponse devrait être plus comme `` maintenir une ancienne version tout en permettant développement à poursuivre sur la ligne principale ", ou" dans le cadre d'une grande expérience ".
Le modèle distribué est beaucoup mieux, je pense, et ne manque que de bons outils graphiques pour devenir le paradigme dominant. Cependant, ce n'est pas aussi largement compris et les concepts sont différents, donc cela peut être déroutant pour les nouveaux utilisateurs.
Je trouve que les conseils de Laura Wingerd & Christopher Seiwald chez Perforce sont vraiment concis et utiles:
* Branch only when necessary.
* Don't copy when you mean to branch.
* Branch on incompatible policy.
* Branch late.
* Branch, instead of freeze.
Voir http://www.perforce.com/sites/default/files/pdf/perforce-best-practices.pdf pour une explication détaillée de chacun d'eux et d'autres bonnes pratiques.
La ramification a plusieurs objectifs:
- Branches de fonctionnalités/bogues. Branches dynamiques et actives qui sont replacées dans le coffre lorsque la fonctionnalité/correction de bogue est terminée.
- Branches statiques (balises dans Subversion, bien qu'il s'agisse essentiellement d'une "branche normale"). Ils fournissent un instantané statique de, disons, une version. Même s'ils pourraient être travaillés, ils restent intacts.
Chaque fois que vous en avez envie.
Vous ne le ferez probablement pas très souvent si vous travaillez avec un SCM centralisé car les branches font partie du référentiel officiel, et cela n'invite pas vraiment à beaucoup d'expérimentation, sans parler du fait que les fusions font vraiment mal.
OTOH, il n'y a pas de différence technique entre une succursale et une caisse dans les SCM distribués, et les fusions sont beaucoup plus faciles. Vous aurez envie de vous ramifier beaucoup plus souvent.
Le besoin de ramification peut également survenir:
Laissant de côté toutes les technicités .....
Branche quand vous savez qu'il est plus facile de fusionner!
Garder à l'esprit que la fusion sera toujours effectuée avec la façon dont le travail est effectué dans un projet.
Une fois cet objectif atteint, tous les autres problèmes tertiaires entreront en jeu.
Lorsque vous devez apporter des modifications, en fonction de votre branche actuelle, non destinées à la prochaine version de cette branche (et pas avant).
Par exemple, nous travaillons généralement sur le tronc. Au moment de la sortie, quelqu'un devra faire un changement que nous ne voulons pas dans la version actuelle (cela peut être avant la sortie, au moment où c'est généralement après la sortie). C'est à ce moment que nous nous branchons, pour mettre la version sur sa propre branche et continuer le développement de la prochaine version sur trunk.