Quand devez-vous vous brancher ?

Question

Lorsque vous travaillez avec un système SCM, quand devez-vous vous brancher ?

Answer 1

En général, l'objectif principal du branchement (une fonctionnalité VCS - Version Control System -) est d'obtenir du code isolement .

Vous avez au moins un qui peut être suffisante pour un développement séquentiel, et qui est utilisée pour de nombreuses tâches en cours d'enregistrement (commit) sur cette même branche unique.

Mais ce modèle montre rapidement ses limites :

Lorsque vous avez un effort de développement (refactoring, évolution, correction de bogues, ...) et que vous réalisez que vous ne pouvez pas faire ces changements en toute sécurité dans la même branche que votre branche de développement actuelle (parce que vous casseriez l'API, ou introduiriez du code qui casserait tout), puis vous avez besoin d'un un autre branche.
(A isoler ce nouveau code pour l'ancien, même si les deux ensembles de codes seront fusionnés ultérieurement)

Donc, c'est votre réponse juste là :
Vous devriez créer des branches chaque fois que vous ne pouvez pas poursuivre et enregistrer deux efforts de développement dans une seule branche.
(sans avoir un historique horriblement compliqué à maintenir).

---

Une branche peut être utile même si vous êtes le seul à travailler sur le code source, ou si vous êtes plusieurs.
Mais vous ne devriez pas faire "une branche par développeur" :
le but "d'isolement" 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 le bogue 23"),
de ne pas isoler une "ressource .

(une branche appelée "VonC" ne signifie rien pour un autre développeur : Et 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 en ayant au moins une idée de ce qu'il est censé en faire)

Une branche n'est pas une étiquette (SVN est un Système de révision dont tente de proposer une fonction de versioning c'est comme faire des branches et des étiquettes dans des répertoires avec une copie de fichier bon marché : cela ne signifie pas qu'une étiquette est une branche)

Définir une branche signifie également définir une flux de fusion Vous devez savoir où fusionner votre branche lorsque vous l'avez terminée.
Pour cela, le chapitre 7 de Practical Perforce (Laura WINGERD - O'Reilly) est une bonne introduction (agnostique aux VCS) au flux de fusion entre différents types de branches : " " Comment les logiciels évoluent " (pdf)

Il définit le terme ligne de codage (branche qui enregistre les étapes significatives de l'évolution du code, soit par des balises à certains points, soit par une fusion importante vers la branche)

Il présente le modèle de la ligne principale (une ligne de code centrale pour enregistrer les versions) et décrit les différents objectifs des embranchements :

• Flux de développement actif : une ligne de code persistante lorsque divers développements séquentiels ont lieu
• tâches branches des branches de courte durée pour des tâches plus spécifiques (la correction de bogues en est un exemple classique, mais vous pouvez également définir une branche pour un effort de fusion dont vous savez qu'il est complexe à réaliser : vous pouvez fusionner, valider et tester dans cette branche de tâche sans introduire de problème pour la branche de développement principale en cours)
• branche de transition pour préparer une version, avec quelques données ou fichiers de configuration spécifiques à la pré-production.
• Branches privées, branches ad hoc et branches éparses pour de très petites tâches, juste pour être en mesure de livrer un travail 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 de VCS : <a href="http://stackoverflow.com/questions/645008/what-are-the-basic-clearcase-concepts-every-developer-should-know/645771#645771">Concepts de base</a><br>(à propos de ClearCase à l'origine, mais également valable pour tout VCS)}

Answer 2

Il existe plusieurs utilisations de la ramification. L'une des utilisations les plus courantes est la séparation de projets qui avaient autrefois une base de code commune. Ceci est très utile pour expérimenter avec votre code, sans affecter le tronc principal.

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

• Feature Branch : Si une fonctionnalité particulière est suffisamment perturbante pour que vous ne souhaitiez pas que l'ensemble de l'équipe de développement soit affecté dans ses premières étapes, vous pouvez créer une branche sur laquelle effectuer ce travail.

• Branche des correctifs : Pendant que le développement se poursuit sur le tronc principal, une branche de corrections peut être créée pour contenir les corrections de la dernière version du logiciel.

Vous serez peut-être intéressé par l'article suivant, qui explique les principes de l'embranchement, et quand les utiliser :

• Ned Batchelder - Démarrage rapide du branchement de Subversion

Answer 3

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

Branche pour chaque tâche que vous avez à accomplir sur, qu'il s'agisse d'une nouvelle fonctionnalité, d'une correction de bogue, d'un test, etc. C'est ce qu'on appelle une branche de sujet, et cela change la façon dont vous travaillez avec votre SCM.

Vous obtenez :

• Une meilleure isolation
• Meilleure traçabilité -> vous associez les tâches aux branches, et non aux changesets individuels, ce qui vous rend libre de commiter autant de fois que vous le souhaitez et n'impose pas de limite comme "un checkin par tâche".
• Les tâches sont indépendantes (elles partent normalement d'une base stable, de sorte que vous vous concentrez uniquement sur votre code, et non sur la correction des bogues de vos collègues), et vous pouvez choisir de les intégrer à un moment donné ou plus tard, mais elles sont toujours sous contrôle de version.
• Vous pouvez facilement réviser le code (à partir du contrôle de version, pas de conneries de pré-commit) avant de passer à la ligne principale.

Des outils qui peuvent le faire :

• Git
• Mercurial
• Plastique SCM

Des outils qui ne peuvent pas le faire :

• SVN
• CVS
• VSS
• TFS
• Perforce

Answer 4

Cela dépend également de l'outil SCM que vous utilisez. Les SCMs modernes (git, mercurial, etc.) rendent de plus en plus facile la création et la destruction de branches à chaque fois que cela est nécessaire. 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 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 important qu'un patch d'une vingtaine de 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.

Answer 5

Lorsque vous devez apporter des changements significatifs et/ou expérimentaux à votre codebase, en particulier si vous voulez commettre des changements intermédiaires, sans affecter le trunk.