Retour : Page Principale > sommaire méthodologie
On y ajoute un principe : les tags de release.
En général il est bienvenu de faire une nouvelle version lorsque les fonctionnalités qu'on a ajoutées sont importantes et/ou nombreuses.
Si les commits ont été bien nommés / commentés, le changelog affiché automatiquement par GitHub (liste des commits depuis le tag précédent) est suffisant, pas la peine d'en rédiger un.
Flux de Travail avec GIT
Dérivé du feature-branch workflow - lire la comparaison avec le git-flow et le résumé des 6 règles (en français).On y ajoute un principe : les tags de release.
Aide sur Git
AideGitPrincipes
- chaque projet a son propre dépôt sur GitHub : https://github.com/telabotanica
- on ne commite jamais directement dans la branche master (sauf exception pour un hotfix tout petit et urgent)
- chaque développement se fait sur une branche de feature, qui est testée, proposée sous forme de pull-request sur GitHub, relue, puis fusionnée dans le master
- la version de test d'un logiciel est toujours branchée sur le master et la version de prod' sur le tag de release le plus récent.
- en cas de hotfix sur la version de prod, le tag de release peut éventuellement être déplacé, mais il est préférable de faire un nouveau tag de release (version mineure)
Quand et comment faire une nouvelle version ?
quand ?
Quand on veut en accord avec le scrum master.En général il est bienvenu de faire une nouvelle version lorsque les fonctionnalités qu'on a ajoutées sont importantes et/ou nombreuses.
comment ?
Pour créer une nouvelle version, créer un tag de release sur GitHub (exemple : https://github.com/telabotanica/tb-auth-php/releases). Ceci créera un tag dans le dépôt, mais aussi une entrée dans le volet releases assortie d'un commentaire.Si les commits ont été bien nommés / commentés, le changelog affiché automatiquement par GitHub (liste des commits depuis le tag précédent) est suffisant, pas la peine d'en rédiger un.