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 du branchement. L'une des utilisations les plus courantes consiste à séparer les projets qui avaient autrefois une base de code commune. Ceci est très utile pour expérimenter votre code, sans affecter le tronc principal.

En général, vous verrez deux types de branches:

• 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 contenir les correctifs de la dernière version publiée du logiciel.

Vous voudrez peut-être consulter l'article suivant, qui explique les principes de la création de branches et quand les utiliser:

• Ned Batchelder - Démarrage rapide du branchement Subversion

En terme général, le but principal du branchement (une fonction VCS - Version Control System -) est de réaliser l' isolation du code .

Vous avez au moins une branche, ce qui peut être suffisant pour le développement séquentiel, et est utilisée pour de nombreuses tâches en cours d'enregistrement (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, corrections de bugs, ...) et que vous vous rendez compte que vous ne pouvez pas faire ces changements en toute sécurité dans la même branche que votre branche de développement actuelle (car vous casseriez l'API, ou introduiriez du code qui casserait tout), alors vous avez besoin d'une autre branche.
(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:
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 à entretenir).

Une branche peut être utile même si vous êtes le seul à travailler sur le code source, ou si vous êtes nombreux.
Mais il ne faut pas faire "une branche par développeur":
le but "isolation" est fait pour isoler un effort de développement (une tâche qui peut être aussi générale que "développons la prochaine version de notre logiciel" ou aussi spécifique que "corrigeons bug 23 "),
pour ne pas isoler une" ressource " .

(une branche appelée "VonC" ne veut rien dire pour un autre développeur: Et si "VonC" sortait du projet? Qu'est-ce que vous êtes censé en faire?
Une branche appelée "bugfix_212" peut être interprétée dans le cadre d'un système de suivi de 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 système de révision qui essaie de proposer des fonctionnalités de versionnage 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 en avez terminé.
Pour cela, le chapitre 7 de Practical Perforce (Laura WINGERD - O'Reilly) est une bonne introduction (VCS agnostique) pour fusionner les flux de travail entre différents types de branches: "" Comment le logiciel évolue "(pdf)

Il définit le terme codeline (branche qui enregistre les étapes d'évolution significatives du code, soit via 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 pour la création de branches:

• Flux de développement actif : une ligne de code persistante lorsque divers développements séquentiels ont lieu
• branches de tâches : branches de courte durée pour une tâche plus spécifique (le correctif de bogue est un classique, mais vous pouvez également définir une branche pour un effort de fusion que vous savez complexe à compléter: vous pouvez fusionner, valider et tester dans cette branche de tâche sans introduire de problème pour la branche principale 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.
• Succursales privées, succursales ad hoc et succursales clairsemées : pour de très petites tâches, juste pour pouvoir valider certains travaux en cours sans attendre l'achèvement formel ou l'examen des tests.
  Cela permet de "s'engager tôt, s'engager souvent".

_{Autres concepts intéressants autour du VCS: Concepts de base
(à propos de ClearCase à l'origine, mais également valable pour n'importe quel VCS)}

Tous les SCM du 21ème siècle vous disent:

Branche pour chaque tâche sur laquelle tu dois travailler , qu'il s'agisse d'une nouvelle fonctionnalité, d'un correctif, 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 obtenez:

• Meilleur isolement
• 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 base de référence stable, vous vous concentrez donc uniquement sur votre code, pas sur la correction des bogues de vos parents), et vous pouvez choisir si vous souhaitez les intégrer à un moment ou plus tard, mais elles sont toujours sous contrôle de version
• Vous pouvez consulter le code facilement (à partir du contrôle de version, pas de conneries pré-commit) avant de frapper la ligne principale

Des outils qui peuvent le faire:

• Git
• Mercuriel
• SCM en plastique

Des outils qui NE PEUVENT PAS le faire:

• SVN
• CVS
• VSS
• TFS
• Forcément

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 en cas de besoin. 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 coffre, vous supprimez la branche.

D'autres SCM, par exemple subversion et CVS, ont un paradigme de branchement beaucoup plus «lourd». Cela signifie qu'une branche est considérée comme appropriée uniquement pour quelque chose de plus grand qu'un patch de vingt lignes. Là, les branches sont classiquement utilisées pour suivre des pistes de développement entières, comme une version précédente ou future du produit.

Lorsque vous devez apporter des modifications significatives 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 les plus récentes (comme git et mercurial), vous créez des branches tout le temps et vous les recréez quand même. Je travaille souvent sur une branche séparée pendant un certain temps simplement parce que quelqu'un a cassé la compilation sur la ligne principale, ou parce que le réseau est en panne, puis je fusionnerai les modifications plus tard quand elles seront corrigées, 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: UnderstandingMercurial .

Dans les systèmes plus anciens avec un référentiel central (comme CVS, SVN et ClearCase), alors c'est un problème beaucoup plus sérieux 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 pour continuer sur la ligne principale », ou« dans le cadre d'une grande expérience ».

Le modèle distribué est bien meilleur, 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 et Christopher Seiwald de 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.

Le branchement a plusieurs objectifs:

1. 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.
2. Branches statiques (balises dans Subversion, bien qu'essentiellement juste une «branche normale»). Ils fournissent un instantané statique de, disons, une version. Même s'ils peuvent être travaillés, ils restent intacts.

Le besoin de ramification peut également survenir:

Chaque fois que vous en avez envie.

Vous ne le ferez probablement pas très souvent si vous travaillez avec un SCM centralisé puisque les branches font partie du référentiel officiel, et cela n'invite pas vraiment à beaucoup d'expérimentation, sans oublier 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 ramifier beaucoup plus souvent.

Lorsque vous devez apporter des modifications, basées sur 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 apporter une modification que nous ne voulons pas dans la version actuelle (cela peut être avant la sortie, pour le moment c'est généralement après la sortie). C'est à ce moment-là que nous branchons, pour placer la version sur sa propre branche et continuer le développement pour la prochaine version sur le tronc.

Laissant de côté tous les détails techniques .....

Branchez quand vous savez qu'il est plus facile de fusionner!

Gardant à l'esprit que la fusion sera toujours effectuée avec la manière dont le travail est effectué dans un projet.

Une fois cela réalisé, tous les autres problèmes tertiaires entreront en jeu.