versionning
Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente | ||
versionning [2019/02/06 17:55] – [Gitlab] benoit | versionning [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:// | ||
- | * 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:// | ||
- | * [[https:// | ||
- | * [[https:// | ||
- | * [[https:// | ||
- | |||
- | ==== New project ==== | ||
- | < | ||
- | git init | ||
- | git remote add origin https://xxx | ||
- | git branch < | ||
- | git checkout < | ||
- | </ | ||
- | |||
- | ==== Process Flow ==== | ||
- | * IDE > Modifications > branch dev > checkout dev > commit > push | ||
- | * Dev (server) > pull (dev) > test ? ok : debug | ||
- | * <hi # | ||
- | * <hi # | ||
- | * FIXME | ||
- | |||
- | ==== Clone existing project ==== | ||
- | * sur le serveur : git clone https://xxx | ||
- | * chown -R bnicolas: | ||
- | * 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. | ||
- | |||
- | * [[http:// | ||
- | * [[https:// | ||
- | |||
- | ==== GitFlow ==== | ||
- | {{ : | ||
- | |||
- | === Branches principales === | ||
- | Origin détient deux branches principales //infinies dans le temps//: | ||
- | * master | ||
- | * develop | ||
- | |||
- | **origin/ | ||
- | |||
- | **origin/ | ||
- | |||
- | Quand le code de **develop** est stable et est prêt à être // | ||
- | |||
- | Par définition, | ||
- | |||
- | === Branches secondaires === | ||
- | Le modèle **GitFLow** intègre des branches secondaires afin d' | ||
- | |||
- | * Feature | ||
- | * Release | ||
- | * Hotfix | ||
- | |||
- | === Feature === | ||
- | * Branche source: **develop** | ||
- | * Branche cible: **develop** | ||
- | * Nom: tout sauf **master**, **develop**, | ||
- | |||
- | La branche **feature** est utilisée pour développer des nouvelles fonctionnalités destinées à une future // | ||
- | |||
- | == Créer une branche feature == | ||
- | < | ||
- | git checkout -b myfeature develop | ||
- | # Switched to a new branch " | ||
- | </ | ||
- | |||
- | == Incorporer une branche feature dans develop == | ||
- | < | ||
- | git checkout develop | ||
- | # Switched to branch ' | ||
- | |||
- | git merge --no-ff myfeature | ||
- | # Updating ea1b82a..05e9557 (Summary of changes) | ||
- | |||
- | git branch -d myfeature | ||
- | # Deleted branch myfeature (was 05e9557). | ||
- | |||
- | git push origin develop | ||
- | </ | ||
- | |||
- | L' | ||
- | |||
- | {{ : | ||
- | |||
- | === Release === | ||
- | * Branche source: **develop** | ||
- | * Branche cible: **develop** et **master** | ||
- | * Nom: // | ||
- | |||
- | 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 // | ||
- | |||
- | 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 // | ||
- | |||
- | 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 == | ||
- | < | ||
- | git checkout -b release-1.2 develop | ||
- | # Switched to a new branch " | ||
- | |||
- | ./ | ||
- | # Files modified successfully, | ||
- | |||
- | git commit -a -m " | ||
- | # [release-1.2 74d9424] Bumped version number to 1.2 | ||
- | # 1 files changed, 1 insertions(+), | ||
- | </ | ||
- | |||
- | bump_version.sh est un script fictionnel qui change certains fichiers dans le // | ||
- | |||
- | La branche **release** peut exister un moment jusqu' | ||
- | |||
- | == 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**. | ||
- | |||
- | < | ||
- | git checkout master | ||
- | # Switched to branch ' | ||
- | |||
- | 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 ' | ||
- | |||
- | 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). | ||
- | </ | ||
- | |||
- | === Hotfix === | ||
- | * Branche source: **master** | ||
- | * Branche cible: **develop** et **master** | ||
- | * Nom: **hotfix-*** | ||
- | |||
- | {{ : | ||
- | |||
- | 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. | ||
- | |||
- | < | ||
- | git checkout -b hotfix-1.2.1 master | ||
- | # Switched to a new branch " | ||
- | ./ | ||
- | # Files modified successfully, | ||
- | |||
- | git commit -a -m " | ||
- | # [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1 | ||
- | # 1 files changed, 1 insertions(+), | ||
- | |||
- | git commit -m "Fixed severe production problem" | ||
- | # [hotfix-1.2.1 abbe5d6] Fixed severe production problem | ||
- | # 5 files changed, 32 insertions(+), | ||
- | </ | ||
- | |||
- | == Incorporer une branche hotfix == | ||
- | Quand elle est finit la branche **hotfix** doit être //merge// dans **master** mais aussi dans **develop**. On s' | ||
- | |||
- | < | ||
- | git checkout master | ||
- | # Switched to branch ' | ||
- | |||
- | 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 ' | ||
- | |||
- | 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). | ||
- | </ | ||
- | |||
- | 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' | ||
- | |||
- | ==== Commit message ==== | ||
- | [[https:// | ||
- | - Séparer le sujet du corps par une ligne | ||
- | - Limiter le sujet à 50 caractères | ||
- | - Capitaliser le sujet | ||
- | - Ne pas finir le sujet avec un point | ||
- | - Ecrire à l' | ||
- | - Limiter la largeur du corps à 72 caractères | ||
- | - Utiliser le corps pour expliquer pourquoi au lieu de comment | ||
- | |||
- | Exemple: | ||
- | |||
- | < | ||
- | Summarize changes in around 50 characters or less | ||
- | |||
- | More detailed explanatory text, if necessary. Wrap it to about 72 | ||
- | characters or so. In some contexts, the first line is treated as the | ||
- | subject of the commit and the rest of the text as the body. The | ||
- | blank line separating the summary from the body is critical (unless | ||
- | you omit the body entirely); various tools like `log`, `shortlog` | ||
- | and `rebase` can get confused if you run the two together. | ||
- | |||
- | Explain the problem that this commit is solving. Focus on why you | ||
- | are making this change as opposed to how (the code explains that). | ||
- | Are there side effects or other unintuitive consequences of this | ||
- | change? Here's the place to explain them. | ||
- | |||
- | Further paragraphs come after blank lines. | ||
- | |||
- | - Bullet points are okay, too | ||
- | |||
- | - Typically a hyphen or asterisk is used for the bullet, preceded | ||
- | by a single space, with blank lines in between, but conventions | ||
- | vary here | ||
- | |||
- | If you use an issue tracker, put references to them at the bottom, | ||
- | like this: | ||
- | |||
- | Resolves: #123 | ||
- | See also: #456, #789 | ||
- | </ | ||
- | |||
- | === Séparer le sujet du corps par une ligne === | ||
- | Tous les commits ne nécessitent pas un sujet et un corps. Dans le cas contraire, résumer le changement effectué en moins de 50 caractères, | ||
- | Il est compliqué d' | ||
- | |||
- | === Limiter le sujet à 50 caractères === | ||
- | Si résumer ce que l'on vient de réaliser en 50 caractères est compliqué, c'est peut-être que l'on commit trop de changements en un. [[https:// | ||
- | |||
- | === Capitaliser le sujet === | ||
- | Commencer tous les sujets par une majuscule | ||
- | < | ||
- | Accelerate to 88 miles per hour | ||
- | vs. | ||
- | accelerate to 88 miles per hour | ||
- | </ | ||
- | |||
- | === Ne pas finir le sujet avec un point === | ||
- | La ponctuation n'est pas nécessaire dans le sujet, de plus l' | ||
- | < | ||
- | Open the pod bay doors | ||
- | vs. | ||
- | Open the pod bay doors. | ||
- | </ | ||
- | |||
- | === Ecrire à l' | ||
- | Git lui même utilise l' | ||
- | < | ||
- | Refactor subsystem X for readability | ||
- | Update getting started documentation | ||
- | Remove deprecated methods | ||
- | Release version 1.0.0 | ||
- | vs. | ||
- | Fixed bug with Y | ||
- | Changing behavior of X | ||
- | </ | ||
- | Un sujet de commit bien formaté doit être en mesure de compléter la phrase: if applied, this commit will. | ||
- | < | ||
- | If applied, this commit will refactor subsystem X for readability | ||
- | vs | ||
- | If applied, this commit will fixed bug with Y | ||
- | </ | ||
- | |||
- | === Limiter la largeur du corps à 72 caractères === | ||
- | Git ne limite par la largeur du corps et rend le commit difficilement lisible lors de la visualisation de log en ligne de commande. Il est conseillé de passer à la ligne au bout de 72 caractères. Aujourd' | ||
- | |||
- | === Utiliser le corps pour expliquer pourquoi au lieu de comment === | ||
- | Bon exemple de //Bitcoin Core// | ||
- | < | ||
- | commit eb0b56b19017ab5c16c745e6da39c53126924ed6 | ||
- | Author: Pieter Wuille < | ||
- | Date: Fri Aug 1 22:57:55 2014 +0200 | ||
- | |||
- | | ||
- | |||
- | | ||
- | | ||
- | |||
- | As exceptmask always included ' | ||
- | | ||
- | | ||
- | with direct exception throwing (which also removes some dead | ||
- | | ||
- | |||
- | As a result, good() is never reached after a failure (there are | ||
- | only 2 calls, one of which is in tests), and can just be replaced | ||
- | by !eof(). | ||
- | |||
- | | ||
- | them. | ||
- | </ | ||
- | En regardant tous les changements fait dans le [[https:// |