meta données pour cette page
  •  

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
certif:procedure:develop:gestionversionpratique [2026/08/11 17:48] – [Aide-mémoire : qui fait quoi, sous le capot] nicolascertif:procedure:develop:gestionversionpratique [2026/09/30 10:38] (Version actuelle) – nicolas
Ligne 1: Ligne 1:
-====== Guide pratique — Cycle de release, étape par étape ======+|{{:undo-2.svg?30|}} [[certif:dm#gestion_des_versions|Retour au dossier de maintenance]]|| 
 +|{{:connexe.jpg?40|}} **Sujets connexes**|[[https://cartographie-fonctionnelle.logeas-web.fr/|Cartographie fonctionnelle de LoGeAs]]\\ [[https://cartographie-fonctionnelle.logeas-web.fr/RapportsVersion|Informations sur la version en cours]]\\ [[certif:procedure:develop:gestionversion]]\\ [[certif:procedure:develop:chainequalificationlivraison]]\\ [[certif:procedure:develop:proceduremiseenligne]]\\ [[certif:procedure:develop:proceduremiseenligne:logeas-web]]|
  
-//Document complémentaire à [[certif:procedure:develop:gestionversion|Procédure de Gestion des Versions]] — celui-ci répond à la question « qu'est-ce que je fais, concrètement, à chaque étape ? ». Destiné au développeur et au chef de projet, pas à un usage certification.//+====== Proc#170 - Guide pratique — Gestion des versions LoGeAs Web ======
  
-===== Vue d'ensemble =====+===== Informations qualité =====
  
-{{:certif:procedure:develop:cycle-release-schema.svg?1000|Vue d'ensemble du cycle de release}}+^Suivi des modifications majeures^^^ 
 +^Date^Auteur^Modifications^ 
 +|11 août 2026|Nicolas MARCHAND|Création du document| 
 +|30 septembre 2026|Nicolas MARCHAND|Alignement sur la chaîne de qualification et de livraison (Proc#168) : le guide se limite au travail personnel, à l'intégration et à la bascule entre versions, et renvoie à Proc#168 pour la qualification, la beta, la recette et la release (suppression des anciennes étapes de publication et de la release sans beta) ; mise au format de la maîtrise documentaire|
  
-^ Étape ^ Qui / quoi ^ Commande ^ +|**Suivi des approbations** |[[https://cartographie-fonctionnelle.logeas-web.fr/UniversProcedure?id=170|Cartographie fonctionnelle – fiche de la procédure]]| 
-| 1. Travail personnel | Développeur, à la main | (aucune — voir détail plus bas) | +|**Objet** |Ce guide décrit les opérations à effectuer pour gérer les versions de LoGeAs Web, depuis le développement individuel jusqu'à la publication d'une version destinée aux utilisateurs.| 
-| 2. Intégration | Développeur | ''/fusion-dev'' | +|**Destinataires** |**- Validation des modifications :** Gérant \\ **- Approbation du document :** Équipe développement|
-| 3. Beta | Développeur ou chef de projet | ''/release-beta'' | +
-| 4. Release client | Chef de projet (validation finale) | ''/release-client'' |+
  
-----+\\
  
-===== Étape 1 — Travail personnel (manuel) =====+===== 1. Objet =====
  
-**Déclencheur :** en continu, dès qu'on commence à développer quelque chose.+Ce guide décrit les opérations pratiques de gestion des versions de LoGeAs Web. Il s'adresse principalement aux développeurs et aux personnes chargées de préparer les publications.
  
-**Ce qu'on fait, à la main :**+Il complète les documents suivants :
  
-  - ''git checkout -b <nom-de-branche>'' depuis la branche de version en cours (ex. ''11.0.25'') — pas de convention de nom imposée. +  * [[certif:procedure:develop:gestionversion|Proc#145 - Procédure de gestion des versions]] : règles générales de versionnage. 
-  - On développe, on teste localement si besoin. +  * [[certif:procedure:develop:chainequalificationlivraison|Proc#168 - Chaîne de qualification et de livraison]] : **déroulé pas à pas de la qualification, de la beta, de la recette et de la release**, portes bloquantes, cas particuliers. 
-  - ''git add <fichiers>'' — **jamais** ''git add -A'' à l'aveugle, on relit ce qu'on ajoute. +  * [[certif:procedure:develop:proceduremiseenligne:logeas-web|Proc#169 - Cycle de release LoGeAs Web]] : fonctionnement technique des scripts.
-  - ''git commit -m "..."'' — message en français, court, orienté fonctionnel. +
-  - ''git push -u origin <branche>'' — sauvegarde régulière, au fil de l'eau.+
  
-**Volontairement aucune vérification ici** (pas de build, pas de tests) : c'est une sauvegarde de travail potentiellement inachevé, pas encore un contrôle qualité.+**Répartition :** ce guide détaille le travail quotidien du développeur (branches, commits, intégration, bascule entre versions). Tout ce qui va de la qualification à la livraison est décrit dans Proc#168, et uniquement là.
  
-**À vérifier soi-même avant de committer :** +===== 2. Environnement de travail =====
-  * Rien de sensible n'est ajouté (secrets, fichiers de config locale, ''dist/'', ''coverage/''). +
-  * Si le changement touche en réalité un comportement partagé (``DGService``, composants génériques), le code doit vivre dans ``logeas-lib``, pas ici.+
  
-----+==== 2.1 Outils ====
  
-===== Étape 2 — Intégration (''/fusion-dev'') =====+Les opérations sont réalisées depuis le poste de développement, avec :
  
-**Déclencheur :** le travail sur la branche personnelle est prêt à rejoindre le tronc commun.+  * Git et l'accès aux dépôts distants ; 
 +  * Node.js et npm ; 
 +  * Angular CLI ; 
 +  * Claude Code, pour les commandes d'assistance du cycle ; 
 +  * les accès aux dépôts ''logeas-web'', ''logeas-lib'' et ''logeas-cartographie'' ; 
 +  * un accès connecté à la cartographie fonctionnelle, pour valider les rapports qualité et faire la recette.
  
-**Ce que la commande fait, dans l'ordre :**+Les commandes ''/fusion-dev'', ''/qualifier-version'', ''/release-beta'', ''/release-client'' et ''/rapport-version-qualite'' sont des commandes Claude Code. Elles ne se saisissent pas comme des commandes shell.
  
-  - ''git fetch'' +==== 2.2 Répertoires ====
-  - ''git checkout <branche-de-version>'' puis ''git pull'' +
-  - ''git log <branche-de-version>..<branche-perso> --pretty=...'' — récupère la liste complète des commits qui vont être intégrés +
-  - ''git merge --no-ff <branche-perso>'' — le message de fusion embarque cette liste de commits, pas juste un titre générique +
-  - ''ng build'' — vérifie que ça compile +
-  - ''npm test'' — tests unitaires (Jest) +
-  - ''npm run lint'' — seulement les **nouvelles** erreurs introduites par le diff comptent, pas la dette préexistante +
-  - Si tout est vert : ''git push'' de la branche de version+
  
-**À vérifier après coup :** +^ Répertoire ^ Usage ^ 
-  * Le commit de fusion contient bien la liste des commits intégrés (pas juste « Merge branch X into Y »). +| ''D:\Developpements\Sources\NewInterfaces\logeas-web'' | Dépôt principal de l'interface et des scripts de livraison | 
-  * Aucun conflit n'a été résolu à l'aveugle sur un point métier — en cas de doute, la procédure doit s'arrêter et demander plutôt que trancher seule. +| ''D:\Developpements\Sources\NewInterfaces\logeas-lib'' | Dépôt des bibliothèques partagées | 
-  * Build/tests/lint sont bien passés **après** la fusion, pas seulement avant (l'intégration de plusieurs travaux peut casser des choses invisibles avant).+| ''D:\Developpements\Sources\NewInterfaces\logeas-cartographie'' | Dépôt de la cartographie fonctionnelle (écran « Rapports de version ») | 
 +| ''D:\Developpements\VersionPublic\LogeasWeb-Test\browser'' | Résultat du build beta | 
 +| ''D:\Developpements\VersionPublic\LogeasWeb\browser'' | Résultat du build de production | 
 +| ''D:\Developpements\VersionPublic\ExecutablesWindows'' | Exécutables des composants utilisés pour les rapports de release |
  
-**Si ça échoue :** la procédure corrige sur place si c'est trivial, sinon elle s'arrête et explique — jamais de ''push --force'', jamais de fusion poussée avec des tests rouges.+Les commandes Claude Code et les scripts se lancent depuis la racine du dépôt ''logeas-web''.
  
-----+===== 3. Vue d'ensemble =====
  
-===== Étape 3 — Beta (''/release-beta'') =====+^ Étape ^ Commande ou opération ^ Qui ^ Décrit dans ^ 
 +| 1. Travail personnel | Git, commits et sauvegardes | Développeur | ce guide, section 4 | 
 +| 2. Intégration | ''/fusion-dev'' | Développeur | ce guide, section 5 | 
 +| 3. Qualification | ''scripts\qualifier-version.bat'' | Développeur | Proc#168 | 
 +| 4. Validation du rapport qualité | carto, écran « Rapports de version » | Valideur | Proc#168 | 
 +| 5. Beta | ''scripts\livrer-beta.bat'' | Développeur | Proc#168 | 
 +| 6. Déploiement sur le serveur de test | copie manuelle | Personne habilitée | Proc#168 | 
 +| 7. Recette de la beta | carto, écran « Rapports de version » | Valideur | Proc#168 | 
 +| 8. Release client | ''scripts\livrer-release.bat'' | Développeur | Proc#168 | 
 +| 9. Déploiement en production | copie manuelle | Personne habilitée | Proc#168 |
  
-**Déclencheur :** la branche de version est jugée stable, prête pour un tour de validation interne.+===== 4. Étape 1 — Travail personnel =====
  
-**Ce que la commande fait, dans l'ordre :**+==== 4.1 Création de la branche ====
  
-  - ''git status'' — vérifie que la branche est propre et à jour avec ''origin'' +Dans le dépôt ''logeas-web'', créer une branche personnelle à partir de la branche de version en cours.
-  - ''npm run build:beta'', qui enchaîne : +
-    * ''node scripts/version.js beta'' — calcule le numéro ''X.Y.Z.W'' (voir règle de numérotation dans la procédure de référence) +
-    * régénération de la licence DevExtreme +
-    * ''ng build --configuration production,beta'' — sortie vers ''LogeasWeb-Test'' +
-  - ''node scripts/release-report.js beta'', qui : +
-    * calcule le diff Git depuis le **dernier tag ''_release''** (jamais depuis le dernier beta — le rapport cumule tout le cycle) +
-    * relance ''npx jest --coverage --json'' pour un résumé de tests à jour (pass/fail, couverture) +
-    * lit la version des 4 composants de la Galaxie LoGeAs directement sur les exécutables compilés (''D:\Developpements\VersionPublic\ExecutablesWindows\'') +
-    * écrit ''src/assets/releases/X.Y.Z.W.html'' + met à jour ''manifest.json'' +
-  - Commit dédié « Preparation version X.Y.Z.W » (``package.json`` + ``version.ts`` + le rapport généré) +
-  - ''git tag -a X.Y.Z.W_beta'' +
-  - ''git push'' + ''git push origin <tag>''+
  
-**À vérifier après coup :** +Exemple :
-  * Le numéro de version généré est bien celui attendu (cohérent avec le nom de la branche). +
-  * Le rapport de release ne signale pas d'échec de test bloquant — s'il y en a, décider **avec l'équipe** si on tague quand même. +
-  * Le build est bien présent dans ''D:\Developpements\VersionPublic\LogeasWeb-Test\browser\''. +
-  * Le rapport est consultable dans l'appli via l'écran « Rapports de release » (Administration, ou directement ''/RapportsRelease'', accessible sans connexion).+
  
-**Ce qui reste manuel :** copier ''LogeasWeb-Test\browser\'' vers le serveur de test — accessible uniquement en bureau à distance, aucune procédure ne le fait à votre place.+<code bash> 
 +git checkout 11.2.0 
 +git pull 
 +git checkout -b feature/nom-fonctionnalite 
 +</code>
  
-----+Le nom de la branche doit permettre d'identifier le travail effectué.
  
-===== Étape 4 — Release client (''/release-client'') =====+==== 4.2 Développement et sauvegarde ====
  
-**Déclencheur :** la beta a été validée (ou directement si aucune beta n'est jugée nécessaire pour ce cycle).+Le développeur réalise ses modifications et les sauvegarde régulièrement.
  
-**Ce que la commande fait, dans l'ordre :**+Exemple :
  
-  - ''git status'' — branche propre et à jour +<code bash> 
-  - Si cette release fait suite à une beta : vérifie que rien d'autre que des correctifs ciblés n'a été ajouté depuis le tag beta (''git log <tag_beta>..HEAD'') — sinon ça mérite peut-être un nouveau tour de beta. +git status 
-  - ''npm run build'', qui enchaîne : +git add src/app/mon-composant 
-    * ''node scripts/version.js release'' — repasse en 3 chiffres, **reprend le même X.Y.Z que les betas du cycle** (jamais de numéro « orphelin ») +git commit -m "Ajout de la fonctionnalité" 
-    * ''ng build --configuration production'' — sortie vers ''LogeasWeb'' +git push -u origin feature/nom-fonctionnalite 
-  - ''node scripts/release-report.js release'' — même mécanique qu'en beta +</code>
-  - Commit dédié « Preparation version X.Y.Z » (``package.json`` + ``version.ts`` + le rapport) +
-  - ''git tag -a X.Y.Z_release'' +
-  - ''git push'' + push du tag +
-  - **''/rapport-tests-qualite''** — uniquement à cette étape, jamais en beta : régénère le rapport qualité NF dans ``logeas-cartographie`` (dépôt frère, pas ``logeas-web``), à partir d'une exécution réelle des tests de ``logeas-web`` **et** ``logeas-lib``+
  
-**À vérifier après coup :** +Avant chaque commit, vérifier les fichiers sélectionnés.
-  * Le build est bien présent dans ''D:\Developpements\VersionPublic\LogeasWeb\browser\''. +
-  * Le tag ne rentre pas en collision avec un tag ''_release'' déjà existant. +
-  * Le rapport qualité NF (``logeas-cartographie``) a bien été régénéré, relu, et **proposé au commit** — jamais commité automatiquement, dans aucun des deux dépôts.+
  
-**Ce qui reste manuel :** copie vers le serveur client (bureau à distance).+Ne pas ajouter de fichiers contenant des secrets, des paramètres locaux ou des fichiers de compilation qui ne sont pas destinés au dépôt.
  
-----+Les tests peuvent être exécutés pendant le développement selon les besoins. Cette étape constitue une sauvegarde du travail personnel et non une validation de l'intégration.
  
-===== Aide-mémoire : qui fait quoi, sous le capot =====+==== 4.3 Fin du travail personnel ====
  
-{{:certif:procedure:develop:guide-pratique-detail.svg?1100|Détail des commandes internes par étape}}+Lorsque le travail est prêt à être intégré :
  
-----+  * vérifier les modifications ; 
 +  * sauvegarder les derniers commits ; 
 +  * s'assurer que la branche personnelle est disponible sur le dépôt distant ; 
 +  * lancer l'intégration.
  
-===== Erreurs fréquentes à connaître =====+La branche personnelle ne doit pas être fusionnée directement dans la branche commune en contournant la procédure d'intégration.
  
-  * **Confondre « beta » et « alpha »** : il n'y a que deux étapes outillées de génération, beta et release. Pas de troisième étape intermédiaire. +===== 5. Étape 2 — Intégration =====
-  * **Lancer ''npm run build'' à la main pour un simple test de compilation** : ça déclenche le bump de version (``prebuild``). Pour juste vérifier que ça compile sans effet de bord, utiliser ''ng build'' directement (c'est ce que fait ''/fusion-dev''). +
-  * **Oublier que le rapport qualité NF ne se met à jour qu'en release**, pas en beta — si besoin d'un état des lieux ponctuel entre deux releases, relancer ''/rapport-tests-qualite'' manuellement. +
-  * **Croire que le déploiement est automatique** : à aucune étape le contenu n'est copié sur un vrai serveur — c'est toujours une action manuelle, via bureau à distance.+
  
-----+==== 5.1 Préparation ====
  
-//Document généré le 11 août 2026, à mettre à jour si le contenu des commandes ''/fusion-dev'', ''/release-beta'', ''/release-client'' ou ''/rapport-tests-qualite'' évolue.//+L'intégration est réalisée avec la commande : 
 + 
 +<code> 
 +/fusion-dev 
 +</code> 
 + 
 +La commande se lance dans ''logeas-web''. Elle identifie la branche de version commune et réalise la fusion de la branche personnelle. 
 + 
 +Avant de poursuivre, vérifier que : 
 + 
 +  * le travail est prêt à être intégré ; 
 +  * la branche personnelle a été sauvegardée ; 
 +  * les éventuels conflits ont été examinés ; 
 +  * la branche cible correspond bien à la version en cours. 
 + 
 +==== 5.2 Contrôles ==== 
 + 
 +La procédure réalise les contrôles techniques après la fusion : 
 + 
 +  * compilation ; 
 +  * tests unitaires ; 
 +  * lint. 
 + 
 +Le développeur vérifie le résultat global, notamment les avertissements et les échecs. 
 + 
 +En cas de conflit concernant le fonctionnement métier, ne pas accepter une résolution automatique sans vérification. 
 + 
 +En cas d'échec bloquant, la branche commune ne doit pas être publiée tant que le problème n'est pas traité. 
 + 
 +==== 5.3 Résultat attendu ==== 
 + 
 +L'intégration est terminée lorsque : 
 + 
 +  * la fusion est effectuée ; 
 +  * les contrôles prévus ont été réalisés ; 
 +  * les éventuels problèmes ont été résolus ; 
 +  * la branche commune a été publiée sur le dépôt distant. 
 + 
 +Le commit de fusion permet de retrouver les changements intégrés. 
 + 
 +===== 6. De la qualification à la livraison ===== 
 + 
 +La qualification, la validation du rapport qualité, la beta, la recette, la release et les déploiements ne sont pas décrits ici : ils le sont pas à pas dans [[certif:procedure:develop:chainequalificationlivraison|Proc#168 - Chaîne de qualification et de livraison]], sections « Cheminements pas à pas » et « Les étapes en détail ». 
 + 
 +À retenir une fois l'intégration terminée : 
 + 
 +  * la suite commence par ''scripts\qualifier-version.bat'', après avoir **poussé** les branches de version de ''logeas-web'' et de ''logeas-lib'' ; 
 +  * **ne rien commiter ni pousser pendant la qualification**, ni entre une beta et sa release ; 
 +  * tout correctif après une beta repart d'une branche personnelle, de ''/fusion-dev'', puis d'une nouvelle qualification ; 
 +  * il n'y a pas de release sans beta recettée conforme. 
 + 
 +===== 7. Cas particulier — Démarrer une nouvelle version ===== 
 + 
 +Lorsqu'une évolution nécessite de passer à une nouvelle version (Proc#168, cas 6), créer la nouvelle branche de version dans ''logeas-web'' et, si la bibliothèque évolue aussi, dans ''logeas-lib''. 
 + 
 +Exemple : 
 + 
 +<code bash> 
 +git checkout 11.2.0 
 +git pull 
 +git checkout -b 11.3.0 
 +git push -u origin 11.3.0 
 +</code> 
 + 
 +La branche doit être **poussée** : une branche sans branche amont est refusée par la qualification. 
 + 
 +L'ancienne branche est conservée avec son historique et ses tags. La nouvelle branche devient la cible des prochaines intégrations. 
 + 
 +Informer l'équipe de ce changement afin que les développements en cours soient correctement réorientés. 
 + 
 +La version candidate est tirée du nom de la branche : la première beta de ''11.3.0'' sera ''11.3.0.1''. 
 + 
 +===== 8. Cas particulier — Correctifs et évolutions en parallèle ===== 
 + 
 +Deux pistes de développement peuvent être maintenues simultanément : 
 + 
 +^ Piste ^ Usage ^ 
 +| Version en production | Correctifs de la version utilisée par les clients | 
 +| Version suivante | Nouvelles fonctionnalités et évolutions | 
 + 
 +Les corrections apportées à la version de production ne sont pas automatiquement reportées sur la version suivante : il faut les y intégrer (Proc#168, cas 7). 
 + 
 +==== 8.1 Bascule entre versions ==== 
 + 
 +''logeas-web'' utilise les bibliothèques de ''logeas-lib'' sous forme de paquets construits. Un simple changement de branche Git ne suffit pas à garantir que les dépendances correspondent à la version souhaitée. 
 + 
 +Le script suivant bascule le poste sur une paire de branches web / lib, reconstruit la bibliothèque et la réinstalle : 
 + 
 +<code> 
 +scripts/switch-lib-version.ps1 
 +</code> 
 + 
 +Les profils sont définis dans : 
 + 
 +<code> 
 +scripts/switch-lib-profiles.json 
 +</code> 
 + 
 +Exemples : 
 + 
 +<code powershell> 
 +.\scripts\switch-lib-version.ps1 -Profile hotfix 
 +</code> 
 + 
 +<code powershell> 
 +.\scripts\switch-lib-version.ps1 -Profile next 
 +</code> 
 + 
 +<code powershell> 
 +.\scripts\switch-lib-version.ps1 -LibBranch 11.3.0 -WebBranch 11.3.0 
 +</code> 
 + 
 +Avant d'utiliser cet outil, vérifier que les dépôts ne contiennent pas de modifications locales non sauvegardées. 
 + 
 +Le script signale les correctifs d'une version antérieure pas encore reportés sur l'autre piste. Examiner ces écarts avant de poursuivre. 
 + 
 +Les profils doivent être actualisés lorsqu'une nouvelle organisation de branches est mise en place. 
 + 
 +===== 9. Commandes et précautions ===== 
 + 
 +==== 9.1 Commandes Claude Code ==== 
 + 
 +^ Commande ^ Utilisation ^ 
 +| ''/fusion-dev'' | Intégrer le travail personnel à la branche de version | 
 +| ''/qualifier-version'' | Vérifier les préconditions de la qualification, puis renvoyer vers ''qualifier-version.bat'' | 
 +| ''/release-beta'' | Vérifier la porte beta, expliquer ce qui bloque, puis renvoyer vers ''livrer-beta.bat'' | 
 +| ''/release-client'' | Vérifier la porte release, expliquer ce qui bloque, puis renvoyer vers ''livrer-release.bat'' | 
 +| ''/rapport-version-qualite'' | Rédiger l'analyse du rapport qualité (appelée par la qualification) | 
 + 
 +Seule ''/fusion-dev'' modifie le dépôt. Les commandes ''/qualifier-version'', ''/release-beta'' et ''/release-client'' **ne livrent rien elles-mêmes**. 
 + 
 +==== 9.2 Génération manuelle d'un build ==== 
 + 
 +Les commandes suivantes génèrent un build **hors chaîne** : 
 + 
 +<code bash> 
 +ng build --configuration "production,beta" 
 +</code> 
 + 
 +<code bash> 
 +ng build --configuration production 
 +</code> 
 + 
 +Elles ne passent pas les portes et ne créent ni rapport, ni tag. ''npm run build'' et ''npm run build:beta'' refont en plus la mise à jour du numéro de version. Dans tous les cas, la version produite est affichée « Version non qualifiée ». 
 + 
 +Elles ne doivent pas être utilisées pour une livraison normale. Leur usage en urgence est décrit dans Proc#168, cas 8. 
 + 
 +==== 9.3 Précautions générales ==== 
 + 
 +Avant toute opération : 
 + 
 +  * vérifier le dépôt et la branche active ; 
 +  * vérifier l'état des modifications locales ; 
 +  * ne jamais utiliser ''git push --force'' sur une branche commune ; 
 +  * ne pas supprimer ou réécrire les tags d'une version publiée ; 
 +  * **ne jamais contourner une porte** : si le blocage est injustifié, c'est un défaut des scripts, à signaler et corriger ; 
 +  * ne pas confondre génération d'un build et déploiement d'une version. 
 + 
 +En cas de doute sur la branche cible, le numéro de version ou la validité d'une publication, suspendre l'opération et demander une vérification. 
 + 
 +===== 10. Aide-mémoire Git et SourceTree ===== 
 + 
 +Les scripts exécutent automatiquement les opérations Git prévues. Le tableau ci-dessous sert au dépannage et aux vérifications manuelles. 
 + 
 +^ Commande Git ^ Équivalent SourceTree ^ 
 +| ''git fetch'' | Bouton Fetch | 
 +| ''git checkout <branche>'' | Double-clic sur la branche | 
 +| ''git pull'' | Bouton Pull | 
 +| ''git status'' | Onglet File status | 
 +| ''git add <fichiers>'' | Sélection des fichiers dans File status | 
 +| ''git commit'' | Bouton Commit | 
 +| ''git merge --no-ff <branche>'' | Merge avec création d'un commit même en cas de fast-forward | 
 +| ''git tag -a'' | Création d'un tag annoté sur le commit | 
 +| ''git push'' | Bouton Push, avec sélection des tags à publier | 
 +| ''git log <a>..<b>'' | Consultation de l'historique entre deux références | 
 + 
 +Un tag créé localement mais non publié ne constitue pas une preuve de publication partagée. 
 + 
 +===== 11. Révision du guide ===== 
 + 
 +Ce guide doit être actualisé lorsque les commandes, les scripts, les branches de version ou les modalités de publication évoluent. 
 + 
 +Les modifications doivent rester cohérentes avec Proc#168 et Proc#169.