Faire ça dans une branche, ça implique d'avoir des données des bugs au même endroits que le code. C'est à mon avis une mauvaise idée: ça pollue, c'est facile d'éditer les infos des bugs sans faire exprès, et surtout ça veut dire que potentiellement, git prend la main et fait une fusion tout seul, donc probabilité non nulle de corrompre les données.
Si tu travaille sur une branche, tu dois faire des fusions régulièrement pour avoir les dernières mise à jour des bugs. C'est déjà assez difficile d'avoir un historique propre juste pour le code, pas la peine d'en rajouter.
Potentiellement, tu dois changer de branche pour accéder à une version plus récente ou parallèle des bugs, donc mettre tes changements en cours dans une stash, checkout, lecture, et retour dans l'autre sens. C'est ni efficace ni simple.
Avoir les données des bugs à part ouvre beaucoup de possibilité, comme par exemple d'avoir des bugs indépendants les un des autres pour un checkout partiel, avoir une gestion des identités propres, etc, etc ...
C'est plus facile de communiquer avec d'autres tracker quand le modèle de donnée n'est pas trop éloigné.
Mais tout ça, ça ne veut pas dire que les bugs ne peuvent pas être "conscient" de la notion de branche. C'est bien plus simple et souple de rajouter ce concept par la suite plutôt que de se lier les mains dans le dos tout de suite.
[^] # Re: Pourquoi une nouvelle branche?
Posté par MichaelMure . En réponse à la dépêche git-bug: un bug tracker distribué intégré dans git. Évalué à 10.
Plusieurs raisons:
Mais tout ça, ça ne veut pas dire que les bugs ne peuvent pas être "conscient" de la notion de branche. C'est bien plus simple et souple de rajouter ce concept par la suite plutôt que de se lier les mains dans le dos tout de suite.