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
Dernière révisionLes deux révisions suivantes
versionning [2019/02/16 18:11] – [Gitlab] benoitversionning [2020/06/10 11:16] – [Upgrade] benoit
Ligne 1: Ligne 1:
-====== Versionning ======+====== Versioning ======
  
 ===== Semantic Versioning 2.0.0 ===== ===== Semantic Versioning 2.0.0 =====
Ligne 42: Ligne 42:
   * [[https://about.gitlab.com/]]   * [[https://about.gitlab.com/]]
  
-==== config ====+==== Upgrade ==== 
 +  * [[https://docs.gitlab.com/ee/policy/maintenance.html#upgrade-recommendations]] 
 + 
 +<code> 
 +sudo apt-get update && sudo apt-get install gitlab-ce 
 +</code> 
 + 
 +==== User Config ====
 check git config check git config
 <code> <code>
Ligne 53: Ligne 60:
 </code> </code>
  
-==== GitFlow ====+===== GitFlow =====
 {{ :gitflow.png?direct&400 |}} {{ :gitflow.png?direct&400 |}}
  
-=== Branches principales ===+==== Branches principales ====
 Origin détient deux branches principales //infinies dans le temps//: Origin détient deux branches principales //infinies dans le temps//:
   * master    * master 
Ligne 69: Ligne 76:
 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**. 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 ===+==== 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//. 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//.
  
Ligne 76: Ligne 83:
   * Hotfix   * Hotfix
  
-=== Feature ===+==== Feature ====
   * Branche source: **develop**   * Branche source: **develop**
   * Branche cible: **develop**   * Branche cible: **develop**
Ligne 83: Ligne 90:
 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**. 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 ==+=== Créer une branche feature ===
 <code> <code>
 git checkout -b myfeature develop git checkout -b myfeature develop
Ligne 89: Ligne 96:
 </code> </code>
  
-== Incorporer une branche feature dans develop == +=== Incorporer une branche feature dans develop === 
 <code> <code>
 git checkout develop git checkout develop
Ligne 107: Ligne 114:
 {{ :gitflow_ff.png?direct&400 |}} {{ :gitflow_ff.png?direct&400 |}}
  
-=== Release ===+==== Release ====
   * Branche source: **develop**   * Branche source: **develop**
   * Branche cible: **develop** et **master**   * Branche cible: **develop** et **master**
Ligne 118: Ligne 125:
 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. 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 ==+=== Créer une branche release ===
 <code> <code>
 git checkout -b release-1.2 develop git checkout -b release-1.2 develop
Ligne 135: Ligne 142:
 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. 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 ==+=== 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**. 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**.
  
Ligne 159: Ligne 166:
 </code> </code>
  
-=== Hotfix ===+==== Hotfix ====
   * Branche source: **master**   * Branche source: **master**
   * Branche cible: **develop** et **master**   * Branche cible: **develop** et **master**
Ligne 168: Ligne 175:
 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. 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 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.  Créer à partir de la branche **master**, afin de corriger un bug sur la prod mais les changements sur **develop** sont instables. 
  
Ligne 186: Ligne 193:
 </code> </code>
  
-== Incorporer une branche hotfix ==+=== 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. 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.
  
Ligne 212: Ligne 219:
 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**. 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**.
  
-==== Commit message ====+===== Commit message =====
 [[https://chris.beams.io/posts/git-commit/|Source]] [[https://chris.beams.io/posts/git-commit/|Source]]
   - Séparer le sujet du corps par une ligne   - Séparer le sujet du corps par une ligne