Différences

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

--- versionning [2018/12/20 14:41] – [Commit message] lpieri
+++ versionning [2020/06/10 11:16] – [Upgrade] benoit
@@ Ligne 1: / Ligne 1: @@
-====== Versionning ======
+====== Versioning ======
 ===== Semantic Versioning 2.0.0 =====
@@ Ligne 27: / Ligne 27: @@
   * <hi #fff200>GitLab > merge dev > master</hi>
   * <hi #fff200>Prod (server) > pull (master) > test ? ok : debug</hi>
+  * FIXME
 ==== Clone existing project ====
@@ Ligne 38: / Ligne 39: @@
 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/]]
+  * [[http://gitlab.betterb.fr/]]
   * [[https://about.gitlab.com/]]
-==== GitFlow ====
+==== 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
+<code>
+git config --list
+</code>
+cache the password for a month
+<code>
+git config --global credential.helper 'cache --timeout=2628000'
+</code>
+===== GitFlow =====
 {{ :gitflow.png?direct&400 |}}
-=== Branches principales ===
+==== Branches principales ====
 Origin détient deux branches principales //infinies dans le temps//:
   * master
@@ Ligne 57: / 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**.
-=== 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//.
@@ Ligne 64: / Ligne 83: @@
   * Hotfix
-=== Feature ===
+==== Feature ====
   * Branche source: **develop**
   * Branche cible: **develop**
@@ Ligne 71: / 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**.
-== Créer une branche feature ==
+=== Créer une branche feature ===
 <code>
 git checkout -b myfeature develop
@@ Ligne 77: / Ligne 96: @@
 </code>
-== Incorporer une branche feature dans develop ==
+=== Incorporer une branche feature dans develop ===
 <code>
 git checkout develop
@@ Ligne 95: / Ligne 114: @@
 {{ :gitflow_ff.png?direct&400 |}}
-=== Release ===
+==== Release ====
   * Branche source: **develop**
   * Branche cible: **develop** et **master**
@@ Ligne 106: / 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.
-== Créer une branche release ==
+=== Créer une branche release ===
 <code>
 git checkout -b release-1.2 develop
@@ Ligne 123: / 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.
-== 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**.
@@ Ligne 147: / Ligne 166: @@
 </code>
-=== Hotfix ===
+==== Hotfix ====
   * Branche source: **master**
   * Branche cible: **develop** et **master**
@@ Ligne 156: / 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.
-== 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.
@@ Ligne 174: / Ligne 193: @@
 </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.
@@ Ligne 200: / 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**.
-==== Commit message ====
+===== Commit message =====
 [[https://chris.beams.io/posts/git-commit/|Source]]
   - Séparer le sujet du corps par une ligne