Outils pour utilisateurs

Outils du site


versionning

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
versionning [2018/12/20 13:41] – [GitFlow] lpieriversionning [Date inconnue] (Version actuelle) – supprimée - modification externe (Date inconnue) 127.0.0.1
Ligne 1: Ligne 1:
-====== Versionning ====== 
  
-===== Semantic Versioning 2.0.0 ===== 
-[[https://semver.org/]] Given a version number MAJOR.MINOR.PATCH, increment the : 
-  * MAJOR version when you make incompatible API changes, 
-  * MINOR version when you add functionality in a backwards-compatible manner, and 
-  * PATCH version when you make backwards-compatible bug fixes. 
- 
-===== Git ===== 
-  * [[web:Git]] 
-  * [[https://fr.wikipedia.org/wiki/Git]] 
-  * [[https://services.github.com/on-demand/downloads/fr/github-git-cheat-sheet/]] 
-  * [[https://fr.atlassian.com/git/tutorials/advanced-overview|Git fonctions avancées]] 
-  * [[https://nvie.com/posts/a-successful-git-branching-model/|Le modèle GitFlow]] 
- 
-==== New project ==== 
-<code> 
-git init 
-git remote add origin https://xxx 
-git branch <branche> 
-git checkout <branche> 
-</code> 
- 
-==== Process Flow ==== 
-  * IDE > Modifications > branch dev > checkout dev > commit > push 
-  * Dev (server) > pull (dev) > test ? ok : debug 
-  * <hi #fff200>GitLab > merge dev > master</hi> 
-  * <hi #fff200>Prod (server) > pull (master) > test ? ok : debug</hi> 
- 
-==== Clone existing project ==== 
-  * sur le serveur : git clone https://xxx 
-  * chown -R bnicolas:www-data folder 
-  * composer update 
-    * resize droplet as needed (error : not enough memory allocated) 
-  *  
- 
-===== Gitlab ===== 
-Nous utilisons Gitlab sur un de nos serveurs pour gérer nos différents projets et leurs évolutions. Nous sommes donc également compétents pour vous accompagner dans le déploiement d'une telle solution de versioning de vos propres projets, applications et sites web. 
- 
-  * [[https://lab.betterb.fr/]] 
-  * [[https://about.gitlab.com/]] 
- 
-==== GitFlow ==== 
-{{ :gitflow.png?direct&400 |}} 
- 
-=== Branches principales === 
-Origin détient deux branches principales //infinies dans le temps//: 
-  * master  
-  * develop 
- 
-**origin/master** est la branche principale où le code source est prêt à être mis en production.  
- 
-**origin/develop** est la branche principale où le code de //HEAD //représentent les derniers changements délivrés pour la prochaine //release//. On l'appelle aussi la branche d'intégration, c'est la source des //nightly builds//. 
- 
-Quand le code de **develop** est stable et est prêt à être //release//, tous les changements sont //mergés// dans **master** et //taggés// avec un //numéro de release//. 
- 
-Par définition, à chaque //merge// dans **master**, c'est une nouvelle //release//. On peut ainsi automatiser les //builds// et la mise en prod à chaque commit sur **master**. 
- 
-=== Branches secondaires === 
-Le modèle **GitFLow** intègre des branches secondaires afin d'aider le développement en parallèle entre les différents membre de l'équipe, facilement suivre les //features//, préparer la mise en prod et assister la réparation des problèmes en prod. Contrairement aux branches principales, ces branches secondaires sont //limitées dans le temps//. Enfin, elles suivent toutes un but précis et respectent des règles strictes comme, la convention de nommage, la branche dont elles sont issues et la branche dans laquelle elles seront //mergées//. 
- 
-  * Feature 
-  * Release 
-  * Hotfix 
- 
-=== Feature === 
-  * Branche source: **develop** 
-  * Branche cible: **develop** 
-  * Nom: tout sauf **master**, **develop**, **release-***, **hotfix-*** 
- 
-La branche **feature** est utilisée pour développer des nouvelles fonctionnalités destinées à une future //release//. La branche **feature** existe  aussi longtemps que que la fonctionnalité est en développement, mais finira par être //mergée// dans **develop**. 
- 
-== Créer une branche feature == 
-<code> 
-git checkout -b myfeature develop 
-# Switched to a new branch "myfeature" 
-</code> 
- 
-== Incorporer une branche feature dans develop ==  
-<code> 
-git checkout develop 
-# Switched to branch 'develop' 
- 
-git merge --no-ff myfeature 
-# Updating ea1b82a..05e9557 (Summary of changes) 
- 
-git branch -d myfeature 
-# Deleted branch myfeature (was 05e9557). 
- 
-git push origin develop 
-</code> 
- 
-L'option //--no-ff// permet de toujours créer un //merge-commit//, même si la branche peut-être //merge// en //fast-forward//. Cela permet d'éviter de perdre des informations sur l'historique de la branche //feature// et regroupe tous les commits qui ont créés cette fonctionnalité. 
- 
-{{ :gitflow_ff.png?direct&400 |}} 
- 
-=== Release === 
-  * Branche source: **develop** 
-  * Branche cible: **develop** et **master** 
-  * Nom: //release-*// 
- 
-Les branches **release** aident la mise en production. Elles autorisent la réparation de bug mineurs, prépare les metadonnées pour la //release// (numéro de version, date de build...). Cela permet de libérer la branche **develop** pour recevoir les fonctionnalités de la prochaine grosse //release//. 
- 
-La branche **release** est créer au moment où **develop** contient toutes les fonctionnalitées de la //release// en cours. En revanche toutes les fonctionnalités de la prochaine //release// ne doivent pas être //mergées// dans **develop**. 
- 
-C'est au moment de la création de la branche **release** que la //release// en cours se voit assignée un numéro de version. 
- 
-== Créer une branche release == 
-<code> 
-git checkout -b release-1.2 develop 
-# Switched to a new branch "release-1.2" 
- 
-./bump-version.sh 1.2 
-# Files modified successfully, version bumped to 1.2. 
- 
-git commit -a -m "Bumped version number to 1.2" 
-# [release-1.2 74d9424] Bumped version number to 1.2 
-# 1 files changed, 1 insertions(+), 1 deletions(-) 
-</code> 
- 
-bump_version.sh est un script fictionnel qui change certains fichiers dans le //working-tree// en fonction du numéro de version attribué. 
- 
-La branche **release** peut exister un moment jusqu'à ce qu'elle soit //mergée// et supprimée. Durant cette période des corrections peuvent être appliquées. 
- 
-== Incorporer une branche release == 
-La branche est //merge// dans **master** ensuite ce dernier //commit// sur **master** est //taggé//. Enfin les changements faits sur la **release** (corrections de bugs) doivent être //merge// sur **develop**. 
- 
-<code> 
-git checkout master 
-# Switched to branch 'master' 
- 
-git merge --no-ff release-1.2 
-# Merge made by recursive. 
-# (Summary of changes) 
- 
-git tag -a 1.2 
- 
-git checkout develop 
-# Switched to branch 'develop' 
- 
-git merge --no-ff release-1.2 
-# Merge made by recursive. 
-# (Summary of changes) 
- 
-git branch -d release-1.2 
-# Deleted branch release-1.2 (was ff452fe). 
-</code> 
- 
-=== Hotfix === 
-  * Branche source: **master** 
-  * Branche cible: **develop** et **master** 
-  * Nom: **hotfix-*** 
- 
-{{ :gitflow-hf.png?direct&400 |}} 
- 
-Les branches **hotfix** aident à la préparation pour la mise en prod. Ellles découlent de la nécessité d’agir immédiatement sur un état non souhaité d’une version en production. Ansi, le développement peut continuer pendant qu'une autre personne peut préparer une correction rapide de la prod. 
- 
-== Créer une branche hotfix == 
-Créer à partir de la branche **master**, afin de corriger un bug sur la prod mais les changements sur **develop** sont instables.  
- 
-<code> 
-git checkout -b hotfix-1.2.1 master 
-# Switched to a new branch "hotfix-1.2.1" 
-./bump-version.sh 1.2.1 
-# Files modified successfully, version bumped to 1.2.1. 
- 
-git commit -a -m "Bumped version number to 1.2.1" 
-# [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1 
-# 1 files changed, 1 insertions(+), 1 deletions(-) 
- 
-git commit -m "Fixed severe production problem" 
-# [hotfix-1.2.1 abbe5d6] Fixed severe production problem 
-# 5 files changed, 32 insertions(+), 17 deletions(-) 
-</code> 
- 
-== Incorporer une branche hotfix == 
-Quand elle est finit la branche **hotfix** doit être //merge// dans **master** mais aussi dans **develop**. On s'assure ainsi que le prochaine //release// contient la correction. 
- 
-<code> 
-git checkout master 
-# Switched to branch 'master' 
- 
-git merge --no-ff hotfix-1.2.1 
-# Merge made by recursive. 
-# (Summary of changes) 
- 
-git tag -a 1.2.1 
- 
-$ git checkout develop 
-# Switched to branch 'develop' 
- 
-git merge --no-ff hotfix-1.2.1 
-# Merge made by recursive. 
-# (Summary of changes) 
- 
-git branch -d hotfix-1.2.1 
-# Deleted branch hotfix-1.2.1 (was abbe5d6). 
-</code> 
- 
-Une seule exception peut être faite. Si une //release// est en cours, soit une branche **release** encore ouverte. Les changements de **hotfix** doivent être //merge// dans **release** au lieu de **develop**. Les changements seront //mergés// dans **develop** au moment de l'incorporation de la branche **release**. 
versionning.1545309716.txt.gz · Dernière modification : 2018/12/20 13:41 de lpieri