Comment contrôler les versions de mon projet sur GitHub

J'essaie de passer autant de temps que possible sur GitHub de nos jours (même si je suis la seule personne dans l'équipe au travail) pour vraiment ressentir comment ça va être comme pour une application d'entreprise du monde réel.

Une question que j'ai est de contrôler la version . Disons que nous avons commencé un projet. Ensuite, les membres de l'équipe ont créé des succursales et s'y sont développés. Lorsque nous sommes prêts pour la production, nous avons fusionné toutes les succursales avec la mastersuccursale. À la fin, nous allons vivre avec la version 1.0.

Maintenant, cette version 1.0est en ligne et nous avons quelques problèmes déposés pour cette version de ce logiciel. Nous aimerions commencer à développer pour la version 1.1afin de résoudre les problèmes que nous avions introduits en précipitant le projet.

Maintenant, la question est la suivante:

Comment devrions-nous contrôler le versioning ici?

Devrions-nous créer une nouvelle branche pour v1.0et y conserver la version 1.0du logiciel et la développer sur certaines branches (ou non), les fusionner avec master, mettre en ligne la version 1.1?

Existe-t-il une convention pour ce genre de situations?

— tugberk
source

Réponses:

J'ai trouvé (et commencé à adopter) le modèle de branche suivant :

Image de nvie.com

^{(image de l'article)}

Il y a beaucoup de bonnes pratiques et de règles strictes décrites dans cet article, je le recommande vivement.

Points d'interêts:

La branche principale est l'endroit où vous balisez vos versions. Aucun développement ne se produit ici. Dans le cas d'un bogue qui a été déployé en production, vous corrigez le bogue sur une branche de correctif, fusionnez en arrière et balisez une nouvelle version.
Le développement se produit sur les branches de développement et de fonctionnalité. Personnellement, je fais des corrections de bugs sur la branche devel et des fonctionnalités sur les branches de fonctionnalités.
Lorsque le logiciel commence à atteindre une version, je bifurque vers une branche de version. La branche de publication est l'endroit où je fais la touche finale. Renforcez les numéros de version, modifiez les métadonnées, etc. Et corrigez les bogues mineurs. Quand il est terminé, je le fusionne pour le maîtriser, le taguer et l'appeler une version.
Les deux branches principales: le maître est la "branche sainte"; son HEAD est toujours le dernier code de production, et develop est la branche nocturne; son HEAD reflète toujours les derniers ajouts (mais éventuellement instables) au code.

Dans votre cas spécifique, les étapes dépendent de la précipitation de cette version. Si ce sont des fonctionnalités qui ont été omises, je reviens à la version de développement et je recommence. S'il s'agit de bogues dans la version déployée, je bifurquerais vers une branche de correctifs, corrigerais les bogues, fusionnerais en arrière et marquerais v1.1. Si c'est les deux, je corrigerais les bugs en premier, puis ajouterais les fonctionnalités en second comme décrit.

— Tamás Szelei
source

Très instructif et détaillé. Et aussi une pratique parfaite. Cela a également beaucoup de sens. Avoir le maître pour la prod ne fait que le rendre facile à entretenir. Je ne suis pas familier avec le balisage d'une branche (ou commit?). Pouvez-vous me donner des détails à ce sujet? comment pouvons-nous faire selon le modèle ci-dessus?

— tugberk

Dans git, la cible du balisage est un commit. Cela signifie que vous dites: "voici ce commit, et je l'appelle désormais" v1.3 "". En pratique, cela signifie que vous basculez vers la branche principale, fusionnez dans la branche de développement (désormais stable), validez et balisez. Ensuite, vous pouvez répertorier toutes les balises, revenir à ce code au cas où vous auriez besoin de voir ce qui est entré en production dans une version antérieure. Il y a un peu plus dans les balises que cela (ce qui est utile pour le développement distribué à grande échelle comme le noyau linux). Si vous êtes intéressé, je vous suggère le livre de progit .

— Tamás Szelei

ProGit est l'un des livres que je vais certainement lire à partir de zéro. Pour l'instant, je ne lis que les parties qui m'intéressent pour faire le travail. Jusqu'à présent, nous avons développé la branche maître et je pense que je devrais le maintenir. Mais je vais ouvrir une autre branche appelée productionet l'utiliser comme masterbranche selon le modèle ci-dessus.

— tugberk

pendant que j'essaye ce modèle, une chose que je lutte est la suivante: il y a des branches de support comme discuté dans l'article donné, les branches de fonctionnalité et de sortie. il peut y avoir plusieurs succursales futures. Par exemple, FeedbackForm est une future branche et ContactForm en est une autre. C'est ok pour ce modèle je suppose? Devrait-il également y avoir plusieurs branches de publication? et si oui, comment les nommer?

— tugberk

Tout d'abord, vous n'avez pas besoin de le suivre à la lettre, il suffit d'avoir des règles que vous respectez. Faites ce qui est le mieux pour vous et le style de votre équipe. Deuxièmement, oui, plusieurs branches de fonctionnalités et de versions sont normales, sauf si vous avez un projet de courte durée avec une fonctionnalité et une version :). La dénomination, selon l'article, est release- * et feature- *. Je suppose que vous avez mis le futur numéro de version à la place de l'astérisque de la version et de l'identifiant du suivi des problèmes en cas de branches de fonctionnalités.

— Tamás Szelei

Ce que j'ai vu la plupart du temps, c'est:

Master est pour vous le produit. Finalement, toute votre future version x.0 sera sur master.
Vous créez une balise / branche pour chaque version en production afin de pouvoir les prendre en charge pour tout client qui en a besoin.
La fusion des correctifs de l'un ou de l'autre consiste à traiter au cas par cas.

— xsace
source

Merci! vous pensez donc qu'il est raisonnable de conserver une branche nommée v1.0, v1.2 est-elle raisonnable?

— tugberk

@tugberk tant que le logiciel correspondant existe dans cette version, il est logique de conserver les branches afin de pouvoir les dériver rapidement si vous avez besoin d'une branche de correctif spécifique. Lorsque le logiciel n'existe plus dans cette version (n'est plus pris en charge, donc plus de travail ne peut se produire), il peut être judicieux de faire une fusion finale de la branche, puis de la supprimer. Vous pouvez même créer un commit final vide (je le fais souvent au début de la branche), juste pour dire "Closing branch XXXX", sinon vous ne conserverez pas l'historique de la branche (reflog peut aider un peu mais c'est par référentiel)

— Patrick Mevzek