Quelle est la méthode recommandée pour séparer le développement actuel du développement de la maintenance dans le logiciel de contrôle de version?

J'ai une application logicielle gérée à l'aide de Git. Je viens de sortir une nouvelle version 2.x que je compte maintenir sur le long terme (corrections de bugs surtout). En attendant, je voudrais commencer à travailler sur la version 3.x. Quelle est la méthode recommandée pour gérer cela? Dois-je créer une branche pour la version 2.x et avoir le développement 3.x sur le maître? ou l'inverse?

version-control git

— laurent
source

Ont des branches différentes pour le développement et stables.

— Odé

Alors, qu'est-ce qui va habituellement dans la branche principale? (jusqu'à présent, je fais toujours tout là-bas)

— laurent

Vous devez décider ce que vous voulez masterdire. Ce n'est qu'une étiquette.

— Odé

Réponses:

Une façon très intéressante de faire les choses a été décrite ici: Un modèle de branchement Git réussi

Je l'ai trouvé très intrigant, mais je ne l'ai pas encore utilisé.

Très bien, comme demandé un (très) bref résumé de ce que dit l'article:

La branche Master représente uniquement tous les jalons terminés (c'est-à-dire les versions 1.0, 1.1, 1.2, etc.)
Le développement se fait dans sa propre branche (nommée commodément "develop", qui aurait pensé?). La branche de développement est fusionnée à nouveau dans la branche principale, chaque fois qu'une version complète de la fonctionnalité est effectuée.
Les branches du développement sont des branches de fonctionnalité. Il s'agit de fonctionnalités uniques pour la prochaine (ou toute future) version. Ils fusionnent avec la branche develop.
Une autre branche issue du développement est la branche "release". Il s'agit d'une branche qui représente une version presque complète où seuls des détails mineurs doivent être nettoyés. Il fusionne avec la branche développement et finalement avec la branche Master
"Hotfix" branche la branche de la branche master si vous trouvez un bogue grave dans une de vos versions (ie "Si l'utilisation entre dans le code konami notre programme reformatera le disque dur principal ..."). Il dérive de la version buggy et, lorsque le correctif est terminé, est fusionné de nouveau dans la branche principale ET la branche de développement.

C'est le court, mais croyez-moi, l'article le décrit de manière plus détaillée et avec le graphique de visualisation utile, il est beaucoup plus facile à comprendre.

— Sorcy
source

Vous devriez inclure une explication sur votre suggestion dans la réponse, de préférence les gens n'auront pas à suivre le lien pour avoir une idée globale du modèle. Les liens ont la mauvaise habitude de se dérober, et les réponses devraient se

— suffire

+1 À peu près ce que nous utilisons au travail, et cela fonctionne vraiment.

— Ed James

Je crois que cela est communément appelé le modèle de "tronc stable" ou de "branche de fonctionnalité".

— sleske

"La branche Master représente uniquement tous les jalons terminés (c'est-à-dire la version 1.0, 1.1, 1.2 etc.)" Je ne voudrais pas d'une branche master avec les versions 1.0, 1.1, 1.2, 2.0, 1.3, 2.1, 1.4, 2.2, 3.0, 1.5 in cet ordre, ce serait vraiment déroutant. Je suppose qu'il y a une supposition implicite qu'il y a au plus un flux sur lequel les versions sont effectuées, ce n'est pas le cas dans ma pratique. Il y a des adopteurs précoces et des gens qui veulent quelque chose de plus stable.

— Programmeur

Eh bien, à long terme, une branche n'est rien de plus qu'une étiquette pour vous permettre de savoir plus facilement ce qui s'y passe. Donc, si vous ne l'aimez pas de cette façon, rien ne vous empêche d'utiliser la branche Master uniquement pour les versions stables du maire et d'avoir une branche "Trial" (ou ce que vous voulez appeler) pour les versions incrémentielles plus petites.

— Sorcy

Mon principe est que plus la branche est à court terme, plus elle devrait être profonde dans la structure de la branche et plus son nom sera précis. Plus la branche est longue, moins elle sera dans la structure de la branche et plus son nom sera générique.

Donc, vous gardez votre maître pour la version à plus long terme (3.X) et vous continuez à nommer cette branche avec un nom générique (maître, tronc, devel, ...) et non spécifique (nom du code de version ou pire numéro de version) qui dépendent trop dans la pratique d'une décision de mise en marché tardive)

Cela n'a pas tellement d'importance dans un système comme git qui a un espace de nom plat pour les branches et où les branches sont équivalentes. Cela importe plus avec un système comme clearcase qui a un espace de noms hiérarchique pour les branches (le nom complet de la branche V4 finit par être principal / v1 / v2 / v3 / v4 ...)

— AProgrammer
source

+1 sauf que je ne sais pas ce que signifie vraiment profond et superficiel dans ce contexte, peut-être pourriez-vous développer un peu ces termes?

— Michael Durrant

Pense aux branches qui font un arbre. Ils peuvent sortir du tronc ou d'une autre branche. Peu profond signifie que le nombre de pas de branchement entre la branche et le tronc est petit, profond signifie que le nombre de pas de branchement est important. Ce qui est petit et important est surtout relatif, mais j'ai vu des schémas pour lesquels chaque nouvelle version était un peu plus loin que la précédente du tronc. Si vous utilisez un espace de noms plat, ce n'est pas si mal. Si l'espace de noms est hiérarchique (clearcase, CVS, RCS, Perforce peut également être utilisé de cette manière), vous obtenez des noms de plus en plus longs.

— AProgrammer