La Taverne à Tonton

Isocode, structure du plugin

_Eric_ — 2024-05-06T12:42:09Z

Les ressources ISO pour les langues

Le plugin utilise des fichiers de code ISO dont l'extraction est faite à partir de ressources diverses sur internet. On détaille ci-après la méthode pour chaque fichier.

Les fichiers SIL des codes de langues ISO-639. ils sont téléchargeables sur la page http://www-01.sil.org/iso639-3/down.... Cette page explique le contenu de chaque fichier et donne le schéma de chacune des tables.

iso639codes.tab : repérer le lien UTF-8 qui suit la phrase « Download ISO 639-3 code set » et faire enregistrer le lien sous. On obtient un fichier nommé iso-639-3.tab qu'il faut renommer en iso639codes.tab.
iso639names.tab : repérer le lien UTF-8 qui suit la phrase « Download ISO 639-3 Language Names Index » et faire enregistrer le lien sous. On obtient un fichier nommé iso-639-3_Name_Index.tab qu'il faut renommer en iso639names.tab.
iso639macros.tab : repérer le lien ISO 639-3 macrolanguage mappings qui suit la phrase « Download » et faire enregistrer le lien sous. On obtient un fichier nommé iso-639-3-macrolanguages.tab qu'il faut renommer en iso639macros.tab.
iso639retirements.tab : repérer le lien UTF-8 qui suit la phrase « Download ISO 639-3 code retirement mappings » et faire enregistrer le lien sous. On obtient un fichier nommé iso-639-3_Retirements.tab qu'il faut renommer en iso639retirements.tab.

Le fichier iso639families.tab est construit en téléchargeant le lien sur la page http://id.loc.gov/vocabulary/iso639... de la Library of Congress. On obtient un fichier iso639-5.tsv qu'il faut renommer en iso639families.tab.

Le fichier iso3166countries.txt est construit à partir de la page du site officiel de l'ISO, https://www.iso.org/obp/ui/fr/#sear.... Afficher 300 résultats par page ce qui permet d'avoir toute la table sur une seule page. Ensuite, sélectionner et copier la table entière sans l'en-tête et la coller dans Excel : on obtient un tableau excel correctement formaté avec le bon charset où il faut juste faire attention que les valeurs numériques ont perdu les zéros qui débutent (005 devient 5). Il faudra donc les réintroduire en créant une colonne via la fonction Texte(valeur, « 00# »). Sélectionner le tableau entier et le copier, puis le coller dans un éditeur comme PHPStorms. Il faut alors recréer un fichier type csv en remettant chaque bloc de 5 lignes sur une seule ligne et séparé par un point virgule en remplaçant les tabulations par le point virgule.
Insérer pour finir la première ligne d'en-tête qui doit être : English name;French name;Alpha-2;Alpha-3;Numeric

Le fichier iso15924scripts.txt est construit en téléchargeant sur la page http://www.unicode.org/iso15924/iso... le fichier zip iso15924.txt.zip en suivant le lien Téléchargez le fichier. Dézipper le fichier pour récupérer le fichier texte et le renommer en iso15924scripts.txt. Comme le fichier ne contient pas d'en-tête il faut rajouter au début du fichier la ligne Code;N°;English Name;Nom français;PVA;Date

Les ressources IANA

Le site IANA fournit un certains nombre de ressources dont un ensemble de registre sur les protocoles informatiques. L'un d'entre eux est le registre des subtags 5646, c'est-à-dire la liste officielle des sous-étiquettes qui composent les étiquettes de langue utilisées dans les protocoles informatiques. La page est accessible à l'url http://www.iana.org/assignments/lan... ou en cherchant le lien « Language Subtag Registry » dans la page des protocoles http://www.iana.org/protocols.
Cette page est décryptée récupérée par la fonction SPIP idoine sans aucune modification de format ou autre.

Les ressources ISO pour les subdivisions

La norme ISO 3166-2 fournit une nomenclature pour certaines subdivisions administratives des pays mais pas pour toutes. Par exemple, pour la France, les régions et départements sont incluses dans l'ISO 3166-2 mais pas les arrondissements, communes et cantons.

L'ISO ne fournit pas gratuitement de fichier pour cette nomenclature, ni par pays ni globalement. Il faut utiliser les pages web de chaque pays pour construire un tel fichier manuellement. La page de base est : https://www.iso.org/obp/ui/fr/#iso:pub:PUB500001:en. Elle propose un tableau des pays (code ISO 3166-1 alpha2) dont seules les cellules en fond vert désigne une nomenclature complète et validée.

En cliquant sur une cellule on affiche une page dans la langue par défaut du navigateur (soit le français) qui présente dans un tableau la liste des subdivisions du pays avec le code ISO, la catégorie, la subdivision mère éventuelle et les traductions dans la langue ou les langues du pays (une ligne par traduction).

Afin d'éviter les accents pour la catégorie, on extrait la page anglaise (changer fr par en dans l'url) sachant que de toute façon les traductions sont dans la langue du pays. Dans certains cas, pays francophones, il faudra combiner la page française et anglaise. De même, pour les langues dont l'écriture n'est pas romane, la traduction est romanisée : on ne doit pas l'identifier avec le code de langue originelle mais comme du français. Par exemple, pour le Maroc il faut remplacer le code ar par fr car en SPIP ar désigne l'écriture arabe et pas romane.

Les ressources ISO des pays

Les codes ISO

La norme ISO 3166-1 fournit la nomenclature internationale des 249 pays mais comme d'habitude aucun fichier source gratuit. Il faut donc le construire à partir d'une page ISO, à savoir : https://www.iso.org/fr/publication/PUB500001.html, lien Liste complète des noms de pays. Le tableau présenté est paginé, il faut choisir 300 items par page de façon à l'afficher en entier. Le tableau affiche 5 colonnes, le nom court anglais, le nom court français et les 3 codes ISO 3166-1 alpha2, alpha3 et numérique.

On copie le tableau dans un fichier csv, en remplaçant les tabulations de séparation par un point virgule et on adapte le nom des colonnes. Enfin, on rajoute une colonne supplémentaire nommée « category » que l'on remplit avec la valeur « country » pour tous les pays.

Les traductions additionnelles

La base de données de terminologie de l'UN, UNTERM, permet d'exporter un fichier de traduction des pays dans les langues russe, chinoise, arabe et espagnole (les langues française et anglaise sont déjà connues). Le fichier excel d'export contient les nom court et long de chacune de ces langues. Nomenclatures n'utilise que les noms courts.

Le problème du fichier obtenu est qu'il ne fait aucune référence à un code ISO du pays. Il faut donc construire le fichier final en utilisant ajoutant un code ISO à pays (un pays = une ligne). En outre, il n'y a que 197 lignes alors qu'il existe 259 pays.

Pour ajouter les code ISO alpha2 on crée une feuille supplémentaire avec le tableau des codes ISO des pays qui contient la traduction française et anglaise. On crée dans la feuille des traductions deux colonnes, fr et en, avec une formule en RECHERCHEV qui permet de trouver le code ISO à partir des traductions en et fr.

De fait, on remarque que quelques traductions sont différentes :

il existe des * dans les traductions UNTERM que l'on peut supprimer
il existe des traductions dans le fichier ISO source qui ne sont pas identiques que celles de l'UNTERM, la différence se trouvant toujours dans les termes entre parenthèses. En général, celles de l'UNTERM sont meilleures car elle intègre les mots « république de » ou « ile » dans le nom et pas dans les parenthèses. Cela est particulièrement évident avec les deux Congos.

On crée donc deux fichiers csv séparés :

celui des traductions UNTERM des pays dont le nom fr et en est identique à l'ISO ;
celui des traductions UNTERM des pays dont le nom fr ou en est différent de l'ISO.

En outre, il existe des noms ISO qui ne possède pas de traduction UNTERM mais dont le nom ISO en ou fr pourrait suivre la même logique que l'UNTERM. On crée un troisième fichier pour ces nouvelles traductions en et fr.

Les ressources GEONAMES

Geonames est un organisme qui fournit des données géographiques soit par le biais de fichiers CSV intégrables dans une base de données soit par l'intermédiaire de services web REST.

Dans Isocode, on utilise Geonames pour compléter la table des pays - iso3166countries - avec les informations contenues dans le fichier Geonames countryInfo.txt disponible à l'adresse http://download.geonames.org/export.... Ce fichier est au format texte de type CSV avec une tabulation comme délimiteur. Il suffit donc d'enregistrer la page précédemment citée et de retoucher le fichier en supprimant les commentaires repérés par un caractère # sauf la ligne précédent le premier pays qui fera office d'en-tête après lui avoir supprimé le caractère #.

Le fichier est in fine renommé en iso3166countries-geonames-info.tab.

Les ressources GEOIP

GeoIP est une librairie PHP qui permet de connaitre les données géographiques associées à un IP. Elle permet en particulier de connaitre le continent désigné par un code à deux lettres.

Il existe une fichier json accessible à cette adresse : https://datahub.io/core/continent-c... qui contient le nom anglais et le code du continent. On le télécharge, on le complète avec le nom français, espagnol, russe, chinois et arabe que l'on récupère dans le fichier M49regions.csv et on le nomme geoipcontinents.json avant de le stocker dans le répertoire services/geoip/ du plugin.

Les ressources UN M49 des régions du monde

Le fichiers M49regions.csv et M49regions_countries.csv sont construits à partir des pages :

Fichier `M49regions.csv`

Pour le fichier M49regions.csv, il faut récupérer chaque table pour les 6 traductions de la page https://unstats.un.org/unsd/methodology/m49/, menu Geographic Regions et, extraire uniquement les régions (laisser les pays que l'on repère par leur code alpha3). Après on construit à la main la liste avec le code M49 de la région (001, 002...) et chaque traduction dans une colonne (les langues sont en, fr, es, ru, ar et zh).
Il faut aussi déterminer le parent à partir de l'arborescence présentée dans la page du site. La catégorie est mise à zone_region pour la plupart sauf les continents au sens GEOIP à qui ont affectent la catégorie continent.

Pour les continents, à partir du moment où l'on choisi de retenir les codes GEOIP, cela revient à choisir le modèle à 7 continents. Ce n'est pas le modèle que l'on vient de saisir dans le fichier M49regions.csv. Il faut donc le modifier comme le précise le renvoi en fin de tableau de la page des regions :

The continent of North America (numerical code 003) comprises Northern America (numerical code 021), Caribbean (numerical code 029), and Central America (numerical code 013

Il faut donc faire les opérations suivantes sur le fichier :

ajouter la ligne de la région North America / Amérique du Nord qui a bien un code M49, le 003 et lui affecter la catégorie continent.
lier cette région à son parent Amériques de code 019
supprimer la région 419 qui ne va plus être utile
lier la région Amérique du Sud 005 à son parent la région Amériques 019 étant donné que 419 a été supprimée et passer la catégorie à continent
lier les régions Amérique Centrale 013, Caraïbes 029, Amérique Septentrionale 021 à son parent le continent Amérique du Nord 003

Les modifications de ce fichier sont assez rares et décrites dans la même page, menu Recent Changes. La dernière modification remonte à 2017.

Fichier `M49regions_countries.csv`

Ce fichier permet de faire le lien entre chaque pays de la liste ISO 3166 et les régions M49. Il suffit donc de garder deux colonnes, le code M49 du pays et le code M49 de sa région parent.

Le plus simple est d'exporter le fichier Excel français de la page https://unstats.un.org/unsd/methodology/m49/overview/ accessible par le menu Fullview.

On ouvre le fichier Excel et on supprime toutes le colonnes à droite de la colonne « M49 Code ». On crée un titre « parent » dans la colonne juste à droite et on y copie la valeur de la région rattachée : pour la déterminer il suffit de prendre la région la plus à droite parmi les 4 niveaux d'arborescence. Une fois fini, on peut supprimer les colonnes de région (8 colonnes) ainsi que la colonne du nom français du pays qui ne nous sert pas.

Pour obtenir 015 au lieu de 15, on duplique les colonnes M49 Code et Parent avec la formule TEXTE(cellule, « 000 ») que l'on recopie ensuite en copie valeur dans les colonnes M49 Code et Parent. On peut alors supprimer les colonnes de calcul et renommer la colonne « M49 Code » en « code_num ».

Enfin, il faut modifier le code_num du pays Antartique de 001 (monde) à 010 qui est le code du continent Antartique (on a donc deux territoires qui ont le même code mais pas utilisés en même temps).

Pour terminer on enregistre le fichier Excel en CSV avec un « ; » en guise de séparateur en le nommant M49regions_countries.csv.

Ce fichier varie peu mais surement plus que celui des régions. Il est facile de le reconstruire si on constate une modification listée dans la page dédiée.
Il est aussi à noter que Taiwan n'apparait pas comme un pays UN M49.

Récapitulatif des modifications proposées

_Eric_ — 2022-03-02T13:16:30Z

Sommaire

Introduction

Cet article a pour but de lister exhaustivement et par nature les actions à entreprendre pour, d'une part, corriger les codes de langues actuels de SPIP et d'autre part, aligner le code de SPIP, des plugins et des outils avec ces changements.

Modifier la liste des langues

Langues à supprimer

Étiquettes à modifier

Étiquettes à vérifier avant modification

Fichier excel récapitulatif.

Nouvelle gestion de la liste des langues

fichier JSON des langues supportées (avec une traduction minimale, ne pourrait-on pas imaginer que seuls les langues avec SPIP traduit soit proposée ?).

[ { "code": "oc_auvern", "composition": { "langue": "oc", "extlang": null, "region": null, "ecriture": null, "variante": "auvern", "usage_prive": null }, "nom": "auvernat", "ancien_code": "oc_auv", "referent": "jojo" }, { "code": "oc_lemosin", "composition": { "langue": "oc", "extlang": null, "region": null, "ecriture": null, "variante": "lemosin", "usage_prive": null }, "nom": "auvernat", "ancien_code": "oc_lms", "referent": "jojo" }, { "code": "fr_x_smurf", "composition": { "langue": "fr", "extlang": null, "region": null, "ecriture": null, "variante": null, "usage_prive": "smurf" }, "nom": "français stroumpf", "ancien_code": "fr_tu", "referent": "juju" }
]

Procédure d'ajout d'une langue : il faut vérifier la correction des attributs de la langue saisis => utiliser ISOCODE

Adaptation du code de SPIP

– inc/lang.php
– inc/traduire.php
– en particulier pour la langue alternative.
– Pour les anciens codes et la compatibilité ???

A partir de lang.json :
– génération de inc/lang_liste.php
– génération de inc/lang_info.php avec la langue alternative voire plus (si réduit à la langue alternative, on pourrait l'appeler lang_alter.php

Traduction des noms de langue

– soit dans le JSON
– soit dans un module de langue à part entière du type lang/lang_xx.php
– soit intégré à un module spip comme ecrire, public ou spip

Renommage des fichiers de langue

– Ceux de spip
– ceux de tous les plugins concernés

Mise à jour de TradLang

– Modification de la liste des langues traduites (via inc/lang_liste ?)
– patch pour la BDD pour renommer les références actuelles aux codes erronés

Mise à jour de Smart-Paquets

Qui utilise aujourd'hui le inc/lang_liste de SPIP

Git avancé

cy_altern — 2020-04-18T12:25:29Z

Des éléments pour une utilisation avancée de Git avec SPIP

Sommaire

Utiliser git pour pusher les mises à jour vers un site en production

Utiliser git pour pusher les mises à jour vers un site en production

Principe :

Créer un dépôt git bare [1] sur le serveur de production avec un hook post commit qui publie ce qu'il reçoit dans le répertoire de prod.

Sur le serveur cible :

Créer le repo git bare :

mkdir monsite.git cd monsite.git git init --bare

Ajouter un hook post receive :

nano hooks/post-receive

#!/bin/bash git --work-tree=/var/www/mon_site --git-dir=/var/repo/monsite.git checkout -f

Passer le fichier en exécutable :

chmod +x hooks/post-receive

En local

Ajouter le dépot distant “prod” :

git remote add prod ssh://user@monserveur.fr/home/user/monsite.git

Pour publier sur la production :

git push prod master

Voir aussi : https://blog.alwaysdata.com/fr/2018/02/05/deployer-sans-peine-avec-git-hooks/
qui détaille la procédure avec notamment un script post commit un peu plus évolué (vérification de la branche poussée par exemple)

[1] A propos des dépôt bar (« nus »), http://www.saintsjd.com/2011/01/what-is-a-bare-git-repository/ donne cette explication :
Un dépôt nu créé avec git init —bare est destiné au... partage. Si vous collaborez avec une équipe de développeurs et que vous avez besoin d'un endroit pour partager les modifications apportées à un repo, alors vous voudrez créer un dépôt nu dans un endroit centralisé où tous les utilisateurs peuvent pousser leurs modifications (le choix le plus facile est souvent github.com). Comme git est un système de contrôle de version distribué, personne ne modifiera directement les fichiers dans le dépôt centralisé partagé. Au lieu de cela, les développeurs clonent le dépôt nu partagé, apportent des modifications localement dans leurs copies de travail du dépôt, puis les renvoient au dépôt nu partagé pour mettre leurs modifications à la disposition des autres utilisateurs.

Installer un SPIP en Git

_Eric_ — 2020-03-22T10:31:25Z

Sommaire

Introduction

Après avoir installé et configuré un environnement Git, puis appris les rudiments des commandes Git de base, il convient maintenant de créer un environnement SPIP sous Git.

Pour ce faire, il est toujours possible d'enchainer les commandes git clone sur l'ensemble des repos qui composent la distribution officielle de SPIP. Néanmoins, il y a plus simple en utilisant l'un des deux outils proposés par la communauté :

checkout, un script PHP ;
ou git_loader, un script bash.

Ces deux outils possèdent un fichier readme.md qui détaille les commandes possibles.

L'outil checkout

Prérequis

L'outil checkout est un script PHP multi-méthodes permettant une syntaxe unifiée Git/SVN/FTP des commandes de checkout. Il est possible d'installer un SPIP ou tout autre repo. Dans ce paragraphe, nous nous concentrerons sur l'installation de SPIP en Git.

Sous Windows, il est nécessaire d'avoir installé le bash git qui fait partie de l'installateur « Git for Windows » (voir l'article Installation de Git). En effet, vous n'aurez pas besoin d'utiliser le .bat et vous pourrez utiliser les mêmes commandes que sous Mac ou *NIX (le terminal par défaut - cmd.exe - est à proscrire).

Cet outil est disponible dans l'organisation spip-contrib-outils de la forge Git de SPIP. Le repo est nommé checkout. Il suffit de télécharger le zip sur la forge https://git.spip.net/spip-contrib-o... et de l'installer dans un répertoire de votre choix. Il est recommandé de placer le script dans un dossier connu du PATH afin d'y accéder plus simplement. Le readme.md détaille en introduction la procédure pour y arriver.

Installation de la distribution officielle de SPIP

En prenant l'hypothèse que le script est bien accessible dans le PATH pour installer le master de SPIP dans le répertoire spip/, il suffit d'invoquer la commande suivante à partir d'un répertoire donné (la racine des sites par exemple) :

$ checkout spip

Depuis la version 1.5.0 du script il est possible sous tous les OS d'utiliser la commande checkout plutôt que checkout.php qui ne fonctionne pas sous Windows.

La paramètre spip n'indique pas le dossier mais la méthode choisie, à savoir, installer un spip. Le dossier n'étant pas précisé c'est le dossier spip/ qui est créé par défaut et la branche master qui est installée.

Si on préfère installer un SPIP 3.2 dans le dossier spip32/ il suffit cette fois d'invoquer la commande :

$ checkout spip -b3.2 spip32

A noter le -b suivi directement du nom de la version qui coïncide maintenant avec la 3.2 (voir les branches sur le repo spip de la forge).

A ce stade nous avons une branche SPIP installée en Git avec ses plugin-dist. Contrairement à git_loader, checkout n'installe pas les plugins « Dev » et « Thèmes ». Par contre, checkout installe SPIP par défaut en HTTPS et pas en SSH. Pour installer une branche master en SSH dans le répertoire spipssh/ il faut invoquer cette fois la commande suivante :

$ checkout spip git@git.spip.net spipssh

Grosse cerise sur le gâteau, il est possible de mettre à jour votre SPIP en rejouant la même commande que précédemment ou de changer de branche active si besoin en utilisant l'option -b. C'est très pratique, mais n'oubliez pas de lancer la commande depuis le même dossier de base sinon vous recréerez un nouveau site.
Par contre, les éventuels plugins spécifiques du dossier plugins/ ne sont pas mis à jour.

L'outil git_loader

Prérequis

L'outil git_loader nécessite que les outils suivants soient disponibles en ligne de commande :

cURL, pour utiliser l'API Gitea de la Forge SPIP ;
et jq, pour phraser le JSON des repos correspondants aux plugins-dist.

Installation de la distribution officielle de SPIP

Cet outil est disponible dans l'organisation spip-contrib-outils de la forge Git de SPIP. Le repo est nommé git_loader. Il suffit de télécharger le zip sur la forge https://git.spip.net/spip-contrib-o... et d'installer le script dans un répertoire connu du PATH afin d'exécuter le script de n'importe où.

Depuis les dernières mises à jour, git_loader sait créer le répertoire de destination ce qui simplifie grandement l'installation. En prenant l'hypothèse que le script est bien accessible dans le PATH, pour installer le master de SPIP dans le répertoire spip/ en utilisant une authentification SSH, il suffit d'invoquer la commande suivante à partir d'un répertoire donné (la racine des sites par exemple) :

$ git_loader.sh -m ssh -d spip

ou la commande suivante si le script a été installé dans le PATH comme un exécutable sans extension :

$ git_loader -m ssh -d spip

Par défaut, git_loader installe la branche master c'est pourquoi il est inutile de le préciser. On indique, par contre, l'authentification SSH car le défaut est HTTPS et, si le répertoire de destination n'avait pas été précisé, l'installation aurait eu lieu dans le répertoire courant au moment du lancement de la commande.

A ce stade la version master de SPIP est installée, plugins-dist compris.

Si l'on voulait installer la branche 3.2, il suffirait d'ajouter l'option -v 3.2 à la commande précédente :

$ git_loader.sh -v 3.2 -m ssh -d spip

L'installation d'une branche n'est possible que pour SPIP 3 car les branches 3.0, 3.1, 3.2, etc sont toutes disponibles pour les plugins-dist.

Installer un jeu de plugins

Pour compléter le SPIP précédemment installé, il nous faut maintenant rajouter les plugins spécifiques au site que nous voulons développer. Pour ce faire, il n'existe pas de solution miracle : il va falloir accumuler les commandes git clone sur l'ensemble des plugins souhaités en espérant que ceux-ci sont tous dans la forge.

Tout d'abord on crée le dossier plugins/ à la racine de notre SPIP et on s'y rend :

$ mkdir plugins $ cd plugins

Ensuite, on enchaine une par une les commandes git clone sur les plugins désirés, par exemple, « YAML » et « Rainette » :

$ git clone git@git.spip.net:spip-contrib-extensions/yaml.git $ git clone git@git.spip.net:spip-contrib-extensions/rainette.git

La seule difficulté est de repérer l'url des repos YAML et Rainette. Pour cela il faut se rendre sur la page de leur repo hébergé sur la forge Git de SPIP (par exemple, https://git.spip.net/spip-contrib-e...) et copier le lien qui s'affiche à coté du label SSH. On peut sélectionner soit le lien SSH soit le lien HTTP en cliquant sur le bouton respectif. Dans notre exemple, nous avons choisi le lien SSH comme depuis le début du guide.

Il est toutefois recommandé d'utiliser checkout pour faire la même chose. L'intérêt est de pouvoir plus facilement choisir une branche ou une révision voire de choisir la méthode Git, SVN ou FTP. L'exemple précédent devient :

$ checkout git -bmaster git@git.spip.net:spip-contrib-extensions/yaml.git $ checkout git -bmaster git@git.spip.net:spip-contrib-extensions/rainette.git

Sans autre précision, les dossiers créés portent le nom du repo.

Enfin, si on utilise toujours les mêmes plugins de base, il peut être intéressant de créer un script bash contenant les commandes d'installation de ces plugins, soit en utilisant des git clone, soit mieux, en utilisant l'outil checkout.

Migrer un SPIP existant

Il n'existe pas de solution immédiate pour convertir un environnement SPIP sous SVN vers le même environnement sous Git. Le plus simple est donc :

renommer le répertoire correspondant à votre SPIP sous SVN en spipold/ ou autre ;
utiliser l'un des outils, checkout ou git_loader, pour recréer votre site avec le même nom de dossier en suivant les procédures décrites préalablement ;
compléter l'environnement SPIP obtenu avec les plugins nécessaires pour recréer exactement le même site que celui sous SVN via des git clone ou mieux, l'outil checkout ;
restaurer l'environnement de départ en copiant à minima le fichier .htaccess si besoin et le contenu des dossiers IMG/, config/. Vous pouvez même copier le contenu de local/ et tmp/ si vous voulez conserver exactement le même état des caches et fichiers temporaires ;
supprimer le répertoire spipold/ devenu inutile.

FAQ Git pour SPIP

_Eric_ — 2020-01-20T13:12:32Z

Cela se fait en une seule commande Git. Il faut se placer dans le dossier correspondant à sa copie locale du dépôt de nom « mondepot » et lancer :

$ git remote set-url origine git@git.spip.net:spip-contrib-extensions/mondepot.git

On considère ici que le dépôt « mondepot » a été déplacé de l'organisation plugin vers l'organisation spip-contrib-extensions.

Cela n'est pas possible. Git considère comme racine le répertoire
trunk/ du svn. Tout ce qui était ailleurs avant ce répertoire, de facto,
n'existe pas pour Git.

Non.

La notification par courriel reprend les informations communiquées
dans le commit qui sont contenues dans la configuration utilisateur de Git ( user.email et user.name). Voir l'article Configuration de Git pour plus de précisions.

Cette configuration n'a rien à voir avec les données saisies pour l'utilisateur sur la forge.

Gitea est un outil libre pour gérer des dépôts Git via une interface web. La forge git communautaire de SPIP utilise gitea pour fournir des services un peu comme ceux de Github, Bitbucket ou Gitlab.com, mais de manière hébergée et gérée par des membres de l'équipe SPIP.

Lorsque l'on travaille sur fork, il peut arriver que la version « officielle » (celle à partir de laquelle le fork a été fait) soit modifiée. La manipulation suivante permet d'intégrer ces modifications (= « mises à jour ») dans le fork :

# Ajouter la branche forkée sous le nom de "upstream": git remote add upstream https://git.spip.net/toto.truc/spip_core.git # Récupérer toutes les branches de upstream/master: git fetch upstream # s'assurer d'être positionné sur la branche master: git checkout master # Rejouer tous les commits manquants : git rebase upstream/master # forcer le push vers votre repo forké : git push -f origin master

Tutoriel de démarrage avec Git

_Eric_ — 2019-12-18T20:17:22Z

Sommaire

Introduction

Ce tutoriel a pour but de vous familiariser avec les commandes de base et les cas d'usage simples que vous rencontrerez souvent. Il illustre tous les changements d'états décrits dans la figure suivante :

Tous les tutoriels se déroulent en ligne de commande pour continuer l'apprentissage des fondements de Git sans le décor et les raccourcis mise en place par les GUI.

Initier un dépôt Git local

Il y a deux façons d'initier un projet local sous Git : en partant juste d'un répertoire travail vide ou en récupérant (on dit cloner en Git) un dépôt distant. Ce tutoriel adresse successivement les deux cas.

Initier un dépôt à partir d'un répertoire vide

On commence par créer le répertoire de travail monprojet/ à la racine de l'utilisateur par exemple et on se rend dans le nouveau répertoire créé.

$ cd ~ $ mkdir monprojet $ cd monprojet

Ensuite, on initie la gestion du projet sous Git en lançant la commande git init.

$ git init Initialized empty Git repository in /Users/eric/monprojet/.git/

De fait, le répertoire .git/ a été créé et initialisé. Vous pouvez naviguer à l'intérieur pour étudier sa structure et noter que la zone d'index (fichier .git/index) n'est pas encore créé et qu'il existe bien un fichier .git/config comme indiqué dans l'article Configuration de Git. La zone de travail est encore vide mais tout est prêt pour commencer à développer votre projet.

En lançant la commande git status on obtient les informations suivantes :

$ git status On branch master No commits yet nothing to commit (create/copy files and use "git add" to track)

Il est important de noter que sans précision, la branche créée par défaut en local s'appelle « master ». C'est la seule qui existe à cet instant.

Cloner un dépôt distant

Pour ce tutoriel on considère que l'accès à la forge SPIP (ici les plugins) est autorisé. Si ce n'est pas le cas, il vous faudra demander l'accès à la forge et faire la configuration SSH comme expliqué dans l'article Configuration de Git.

On se propose donc de cloner le plugin Rainette en local. Pour ce faire, on se positionne à la racine de l'utilisateur et on utilise la commande git clone en fournissant l'URL du dépôt :

$ git clone git@git.spip.net:plugin/rainette.git Cloning into 'rainette'... remote: Counting objects: 2603, done. remote: Compressing objects: 100% (886/886), done. Receiving objects: 79% (2057/2603), 2.37 MiB | 4.73 MiB/seceiving objects: 78% (2031/2603), 2.37 MiB | 4.73 MiB/s Receiving objects: 100% (2603/2603), 2.82 MiB | 5.02 MiB/s, done. Resolving deltas: 100% (1643/1643), done.

Etant donné qu'on n'a pas précisé le répertoire destination, Git a créé le répertoire de travail ~/rainette/ et l'a peuplé avec une copie des fichiers de la dernière version du plugin. On peut aussi noter la création du ./git qui contient quasiment toutes les données dont le serveur dispose. Toutes les versions de tous les fichiers pour l'historique du projet sont téléchargées.

En lançant un git status à partir du répertoire rainette/ on obtient :

$ git status On branch master Your branch is up to date with 'origin/master'. nothing to commit, working tree clean

Il est à noter que la branche locale se nomme encore « master » et que la branche distante d'où provient les fichiers extraits se nomme par défaut « origin/master ».

Consigner les modifications du dépôt local

Ce tutoriel explique comment ajouter des fichiers au dépôt Git et enregistrer les modifications sur des fichiers existants. Les exemples choisis permettent d'illustrer les différents états des fichiers décrits dans l'article Les bases de l'utilisation de Git.

Ajouter un fichier au dépôt Git

Reprenons le premier tutoriel avec notre répertoire de travail ~/monprojet/ vide à l'exception du répertoire de base Git (.git/). Ajoutons un fichier README.md dans le répertoire de travail et lançons la commande git status.

$ git status On branch master No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) README.md nothing added to commit but untracked files present (use "git add" to track)

Git a bien détecté l'ajout du fichier README.md dans la zone de travail mais indique qu'il est non suivi (untracked) et qu'il est possible d'utiliser la commande git add pour l'inclure dans les fichiers suivis :

$ git add README.md $ git status On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: README.md

Le fichier README.md vient de passer dans l'état indexé (staged) : il est donc prêt à être validé (commited) et à être intégré dans le premier instantané (commit) de Git. On lance donc la commande git commit en n'oubliant pas de préciser un message :

$ git commit -m "ajout du fichier readme" [master (root-commit) 8049316] ajout du fichier readme 1 file changed, 2 insertions(+) create mode 100644 README.md $ git status On branch master nothing to commit, working tree clean

Dans la commande git commit le fichier a été omis ce qui enjoint Git de valider tout le contenu de la zone d'index qui cette fois est réduit au fichier README.md. La commande git status confirme que la branche « master » ne contient plus de modifications non intégrées au dépôt.

Modifier un fichier suivi par Git

Supposons maintenant que nous souhaitions faire des corrections dans notre fichier README.md. On édite le fichier et on y rajoute une ligne par exemple. On sauvegarde et on lance la commande git status :

$ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: README.md no changes added to commit (use "git add" and/or "git commit -a")

Git a bien détecté un changement sur un fichier suivi dans le dépôt et il le précise en disant que le changement n'est pas indexé (not staged). Il est donc nécessaire d'utiliser encore la commande git add pour insérer la modification dans la zone d'index afin qu'elle soit prise dans le prochain commit :

$ git add README.md $ git status On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: README.md

Git nous informe que le fichier README.md est prêt à être validé (to be committed). On lance donc la commande git commit avec un message :

$ git commit -m "première modification du fichier readme" [master 6c1d1c9] première modification du fichier readme 1 file changed, 1 insertion(+) $ git status On branch master nothing to commit, working tree clean

Pour visualiser notre travail jusqu'à maintenant on lance la commande git log qui fournit la liste des commits effectués sur la branche master de notre dépôt classés du plus récent au plus ancien :

$ git log commit 6c1d1c9d6ea265117da0ea8d523c9ae4b2bad111 (HEAD -> master) Author: Jean Martin <jean@martin.net> Date: Wed Dec 18 16:09:53 2019 +0100 première modification du fichier readme commit b5d9bd0a40d88d6bfeeefb6d47cc9a94a8715d0c Author: Jean Martin <jean@martin.net> Date: Wed Dec 18 14:24:07 2019 +0100 ajout du fichier readme

Supprimer un fichier suivi par Git

Avant de démarrer le tutoriel, il faut adapter notre zone de travail sous Git en rajoutant deux fichiers quelconques sous suivi Git (copie des fichiers, git add et git commit) :

$ git add *.txt $ git commit -m "ajout de 2 fichiers a supprimer" [master 5e5763e] ajout de 2 fichiers a supprimer 2 files changed, 146 insertions(+) create mode 100644 INSTALL.txt create mode 100644 htaccess.txt

Pour supprimer l'un des deux fichiers, le premier réflexe est d'envoyer le fichier dans la corbeille de son explorateur/finder ou d'utiliser le shell avec la commande rm. Lançons donc la commande shell rm sur l'un d'eux et regardons le résultat sur le dépôt :

$ rm htaccess.txt $ git status On branch master Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) deleted: htaccess.txt no changes added to commit (use "git add" and/or "git commit -a")

Comme on pouvait s'y attendre, même si le fichier a bien disparu de la zone de travail Git considère que cette modification n'est pas prête à être enregistrée et considère toujours le fichier htaccess.txt comme étant suivi sous. Il faut donc encore une fois, indexer la modification par git add et l'enregistrer dans le dépôt Git avec git commit.

$ git add htaccess.txt $ git commit -m "suppression du fichier htaccess" [master 6dea8f5] suppression du fichier htaccess 1 file changed, 133 deletions(-) delete mode 100644 htaccess.txt

Néanmoins, il est possible de réaliser cette opération autrement en utilisant uniquement des commandes Git. La commande git rm supprime le fichier physiquement de la zone de travail et indexe la suppression dans la zone d'index. Ensuite la commande git commit va enregistrer la suppression dans le dépôt.

$ git rm INSTALL.txt $ rm 'INSTALL.txt' $ git status On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) deleted: INSTALL.txt $ git commit -m "suppression du fichier INSTALL par git rm" [master d14d34a] suppression du fichier INSTALL par git rm 1 file changed, 13 deletions(-) delete mode 100644 INSTALL.txt

Pour conclure, on peut afficher le contenu de notre répertoire de travail et lancer un git log pour consulter tous les commits effectués depuis le début de ce tutoriel :

$ ls -l total 8 -rw-r--r--@ 1 jean staff 74 18 déc 19:32 README.md $ git log commit d14d34a28cc8bbe8cbf153e0ab1a6a0a97a766c8 (HEAD -> master) Author: Jean Martin <jean@martin.net> Date: Wed Dec 18 21:09:39 2019 +0100 suppression du fichier INSTALL par git rm commit 6dea8f5a2e422cef94ea398ec001e8b08384e751 Author: Jean Martin <jean@martin.net> Date: Wed Dec 18 20:51:11 2019 +0100 suppression du fichier htaccess commit 5e5763e3db5c128b96dac6c3474af0151db2a9bf Author: Jean Martin <jean@martin.net> Date: Wed Dec 18 20:44:32 2019 +0100 ajout de 2 fichiers a supprimer commit 0897426ef844462048157ab32c44eefdb666aec3 Author: Jean Martin <jean@martin.net> Date: Wed Dec 18 19:34:06 2019 +0100 premiere modification du fichier readme commit 804931660f1f9681ba11a92f077f910413f75e56 Author: Jean Martin <jean@martin.net> Date: Tue Dec 17 20:38:40 2019 +0100 ajout du fichier readme

Pousser les modifications locales sur un dépôt distant

Supposons que nous avons cloné un dépôt de la forge SPIP et fait des modifications en locales, modifications que nous avons bien validées dans la branche master locale. Même si Git nous permet de travailler aisément en local il arrive un moment où il faut partager nos modifications avec le dépôt distant. On dit alors qu'on pousse (push) les modifications locales sur le serveur.

La commande pour ce faire est la suivante :

$ git push origin master ...

On reconnait le serveur distant origin et la branche locale dont on pousse les modifications, à savoir, master (origin et master sont créés par défaut lors de la commande git clone, voir le début de l'article). Cette commande ne fonctionne que si vous avez cloné depuis un serveur sur lequel vous avez des droits d'accès en écriture et si personne n'a poussé dans l'intervalle. Mais nous reviendrons sur ce sujet dans l'article sur la gestion des branches.

Les bases de l'utilisation de Git

_Eric_ — 2019-12-16T13:47:16Z

Sommaire

Introduction

L'objectif de cet article n'est pas de répéter une nième fois ce que l'on peut trouver déjà sur le web mais de donner des liens de formation et quelques notions pour une utilisation basique de Git. L'article Plugin Moteur de Notifications / Notification Engine complète le présent article par des cas d'usage rencontrés quotidiennement pour contribuer à SPIP.

Liens d'apprentissage et de référence

Les liens suivants sont recommandés pour se familiariser avec les principes et les commandes de Git et pour consulter les manuels de référence des commandes :

le chapitre Les bases de Git du livre ProGit et la référence des commandes Git proposée sur le même site ;
le site Backlog, ses tutoriels et sa référence d'utilisation ;
la page Git c'est facile du site de Cédric.

Notions de base de Git

Une gestion d'instantanés

Tous les systèmes de gestion de version gèrent une « base de données » des fichiers, des modifications de ces fichiers et des versions associées (dossier .svn/ ou .git/). Mais Git a une gestion particulière de ces données qui lui confère un avantage certain.

SVN et d'autres systèmes de gestion de version considèrent qu'une version d'un projet est constituée des fichiers initiaux et de la suite des modifications apportées à ces fichiers.

Git agit tout autrement en considérant qu'une version d'un projet est un instantané de tous les fichiers gérés (snapshot). Bien entendu, les fichiers non modifiés ne sont pas dupliqués d'une version à une autre mais juste identifiés par un lien vers le dernier fichier identique. De fait, Git gère une suite d'instantanés.

Une gestion locale

La base de données de Git (le fameux dossier .git/) contient l'ensemble de l'historique du projet. De fait, la plupart des actions Git vont se dérouler en local contrairement à SVN ou autres. Cela est notable sur les performances et sur la capacité à travailler sans connexion.

De fait, pour la plupart des opérations, Git ne fait qu'ajouter des données à sa base de données ce qui rend le système très robuste : contrairement aux autres systèmes, il est presque impossible de perdre des modifications une fois qu'elles ont été enregistrées d'une façon ou d'une autre dans la base Git locale.

Des zones et des états

La zone de travail (appelée aussi working tree ou working directory) est constituée des fichiers du répertoire de travail dans lequel figure une version donnée du projet géré sous Git : les fichiers physiques du projet dans la version concernée que l'on va éditer. Dans la zone de travail :

certains fichiers sont gérés sous Git (tracked). Il peuvent dans ce cas être avoir été modifiés par rapport à la version du dépôt Git.
d'autres ne sont pas gérés sous Git (untracked). Cet état peut être temporaire (lorsqu'on crée un nouveau fichier du projet) ou permanent (fichier ignoré).

Le répertoire de travail contient à sa racine le répertoire .git/ qui matérialise la base de données de gestion du projet sous Git. Ce répertoire Git contient :

le dépôt Git appelée aussi repository ou repo qui stocke l'historique et le détails des modifications enregistrées (commits) sous la forme d'instantanés (donc le dépôt contient sous une forme optimisée les états de tous les fichiers) ;
et une zone d'index qui a pour but de préparer les commits en stockant les différences entre la zone de travail et le dépôt.

Cette organisation amène Git à considérer différents états pour les fichiers, états qui sont calculés par rapport au dernier instantané enregistré dans le dépôt :

les fichiers non suivis sous Git ou untracked ;
les fichiers modifiés ou modified par rapport au dernier instantané, mais pas encore marqués pour faire partie du prochain instantané ;
les fichiers indexés ou staged, modifiés et marqués dans leur version actuelle pour faire partie du prochain instantané du projet ;
les fichiers validés ou commited, pour lesquels les données d'instantané sont stockées en sécurité dans la base de données Git locale. En fait, l'état de ces fichiers correspond aussi à inchangé ou unmodified par rapport au dernier instantané.

L'illustration qui suit explique comment un fichier passe d'un état à un autre et suite à quelle action ou commande Git.

Dépot local et dépot distant

Il existe deux types de dépôt Git : local et distant.
Le dépôt local est celui qui est hébergé sur votre machine. Le dépôt distant est installé sur un serveur partagé accessible ou pas via une forge par de multiples utilisateurs.

Si l'on développe sur un dépôt local (on a vu que les actions sont toutes faites dans la base Git locale), de temps à autres, il est aussi nécessaire de synchroniser notre dépôt local avec un dépôt distant. C'est le cas des développeurs du Core de SPIP qui partagent le dépôt distant du Core de SPIP sur la forge Gitea de la communauté.

Il existe donc des commandes spécifiques de Git qui permettent cette synchronisation dans les deux sens.

Commandes Git de base

`git help`	affiche les explications sur les commandes Git ou sur une commande particulière à préciser à la suite du help : `git help init`.
`git config`	permet de modification la configuration Git système, utilisateur ou du dépôt courant.
`git init`	initialise un nouveau dépôt Git dans un répertoire local qui devient de facto une zone de travail pour Git. Le sous-répertoire `.git/` est créé et initialisé.
`git clone`	copie un dépôt distant dans un répertoire local. En fait, le sous-répertoire `.git/` est copié du serveur, installé dans le répertoire de travail que Git a créé et, par défaut, le dernier instantané est extrait de la base Git pour peupler la zone de travail.
`git status`	vérifie le statut de votre dépôt local et affiche les modifications entre le dernier instantané et l'état actuel de la zone de travail et de la zone d'index.
`git add`	porte à l'attention de Git un fichier non suivi ou indexe un fichier suivi venant d'être modifié. Dans tous les cas, le fichier passe à l'état indexé (staged) dans la zone d'index.
`git rm`	supprime un fichier de la zone de travail et de la zone d'index ou uniquement de la zone d'index. Cette commande ne supprime jamais un fichier de la zone de travail uniquement.
`git commit`	par défaut, cette commande enregistre dans le dépôt Git un instantané des modifications (« commit ») présentes dans la zone d'index, les modifications non indexées n'étant pas prises en compte. Cette action nécessite d'être commentée avec un message précisant les raisons du commit : `git commit -m "Mon message"`. Si l'option -m est omise, Git lance l'éditeur configuré pour saisir le message.
`git log`	affiche la liste des modifications enregistrées dans le dépôt Git appelée aussi « log de commits ». Cette commande possède de multiples options pour obtenir l'affichage désiré.
`git fetch`	récupère toutes les données d'un dépôt distant qui ne sont pas encore dans la base Git locale. La commande fetch tire les données dans votre dépôt local mais sous sa propre branche — elle ne les fusionne pas automatiquement avec aucun de vos travaux ni ne modifie votre copie de travail
`git pull`	agit par défaut comme fetch mais fusionne automatiquement les modifications récupérées sur le dépôt distant dans la branche locale et met donc à jour la zone de travail.
`git push`	pousse les modifications validées d'une branche locale vers une branche distante

Configuration de Git

_Eric_ — 2019-12-14T17:50:01Z

Sommaire

Principes de base

Lien tutoriel : https://git-scm.com/book/fr/v2/D%C3...

L'installation terminée il est possible d'invoquer Git au travers d'une fenêtre Bash (la commande git est connue car on a adapté le PATH en conséquence à l'étape d'installation). Par exemple, on vérifie la version installée en tapant la commande git --version dans l'invite de commande.

$ git --version git version 2.25.0

Maintenant, pour utiliser Git de façon extensive, il est nécessaire de définir une fois pour toute quelques paramètres de configuration persistants comme l'identité de l'utilisateur. Pour ce faire, Git propose un outil git config qui génère des fichiers de configuration :

soit au niveau système (pour tous les utilisateurs). Ce fichier n'existe pas toujours. Pour le créer, il faut invoquer la commande git config avec l'option --system et les paramètres désirés. Ce paramétrage est rarement utile, on en parlera plus dans la suite de cet article.
soit au niveau de l'utilisateur et s'appelle ~/.gitconfig [1]. Pour le mettre à jour, il faut invoquer la commande git config avec l'option --global.
soit au niveau d'un dépôt local (répertoire Git). Dans ce cas, il s'appelle .git/config, quelque soit l'OS.

Ces fichiers sont aussi consultables et modifiables par un éditeur de texte.

Configuration classique au niveau utilisateur

Lien tutoriel : https://git-scm.com/book/fr/v2/Pers...
Lien de référence de l'outil git config : https://git-scm.com/docs/git-config.html

Pour configurer son identité, à savoir, le nom de l'utilisateur, Jean Martin et son email, jean.martin@spip.org, il faut lancer les commandes suivantes à l'invite de commande (Git Bash pour Windows ou Terminal pour MacOS) :

$ git config --global user.name "Jean Martin" $ git config --global user.email jean.martin@spip.org

Pour définir l'éditeur de texte qui sera lancé pour saisir les messages (inutile quand on utilise un GUI mais nécessaire si on utilise uniquement l'invite de commande), il faut préciser à Git le chemin vers l'exécutable en utilisant la commande suivante :

$ git config --global core.editor emacs

Il est aussi possible de changer les couleurs utilisées pour repérer les changements de code (ajout, modification, suppression), de définir une modèle pour les messages de commits, une clé PGP pour signer les commits et bien d'autres choses décrites dans la documentation de référence de l'outil git config.

Configuration des fichiers ignorés

Lien tutoriel : https://www.atlassian.com/git/tutor...
Lien de référence du gitignore : https://git-scm.com/docs/gitignore

Git donne la possibilité d'exclure des fichiers ou des modèles de fichier du versionnage. Par défaut, ces fichiers ne seront jamais ajoutés au dépôt Git. Cette configuration est spécifique à un dépôt Git et le fichier de nom .gitignore est positionné en général à la racine du dépôt et s'applique à toute l'arborescence. Il est aussi possible de rajouter d'autres fichiers de ce type dans une sous-arborescence sachant que les .gitignore s'applique en cascade du haut (moins prioritaire) en bas (plus prioritaire).

Maintenant, il est possible de définir une liste d'exclusions au niveau de l'utilisateur qui s'appliqueront à tous les dépôts locaux de celui-ci. Pour cela il faut utiliser la commande suivante qui configure ce fichier d'exclusions global :

$ git config --global core.excludesfile ~/.gitignore_global

Il est classique d'utiliser le nom .gitignore_global pour désigner ce fichier et de le placer à la racine de l'utilisateur (C:\Users\nom_user\ pour Windows en anglais ou C:\Utilisateurs\nom_user\ pour la version française).

Une fois créé, le fichier doit être édité et complété avec les motifs définissant les fichiers à ignorer. Il est conseillé d'utiliser les commentaires pour préciser l'objectif de chaque motif. Par exemple :

# Exclure les fichiers .bak et .log *.bak *.log

La page suivante décrit la grammaire des motifs : https://www.atlassian.com/git/tutor.... Github propose aussi une liste de modèles de .gitignore en fonction du langage (https://github.com/github/gitignore).

Configuration des droits d'accès

Une fois que vous aurez effectué des modifications sur votre dépôt Git local, il sera nécessaire de les pousser sur le serveur Git distant (à l'instar du commit SVN). Pour ce faire, il faut que vous soyez autorisé à accéder au dépôt distant en écriture.

Git supporte les protocoles HTTPS et SSH. HTTPS requiert une authentification classique par login et mot de passe mais l'utilisation de SSH est fortement recommandée car elle est simple et très sécurisée. C'est la méthode que nous allons décrire ci-après.

Pour utiliser SSH, il vous faut une paire de clés attachée à un compte utilisateur. L'une des clés est dite privée car elle est destinée à rester sur l'ordinateur de l'utilisateur (souvent nommée id_rsa) et l'autre est dite publique car c'est elle qui est copiée sur les serveurs avec qui on veut communiquer (souvent nommée id_rsa.pub). Par défaut, ces clés sont créées dans le dossier ~/.ssh (ou C:\Users\nom_user\.ssh\ sous Windows en anglais).

Si vous n'en disposez pas déjà, vous devrez générer une paire de clés SSH. Pour cela, il faut lancer la commande ssh-keygen à l'invite de commande comme suit :

$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/Users/nom_user/.ssh/id_rsa):

Le mieux est d'accepter le nom par défaut proposé pour le fichier en pressant la touche retour. Un mot de passe est alors requis deux fois : c'est une sécurité supplémentaire mais cela pose parfois quelques soucis avec les GUI si on n'enregistre pas correctement ce mot de passe. Il est donc possible de le laisser vide en pressant deux fois la touche retour. Le répertoire ~/.ssh contient maintenant les fichiers id_rsa et id_rsa.pub.

Si vous souhaitez ajouter un mot de passe à votre clé SSH suivez le tutoriel d'Atlassian https://confluence.atlassian.com/bi... et l'utilisation du ssh-agent.

Si le serveur Git est motorisé par une forge comme Github, Bitbucket, Gitlab.com ou une forge communautaire comme celle de SPIP sous Gitea, il suffit de se rendre sur son compte et d'y ajouter la clé publique générée. Pour ce faire, il est nécessaire de copier son contenu complet (le fichier id_rsa.pub est éditable par tout éditeur de texte) dans l'emplacement demandé par la forge. Si aucune forge n'est utilisée, il suffit de fournir sa clé à l'administrateur du serveur Git.

Pour la forge SPIP propulsée par Gitea voilà à quoi ressemble l'onglet Clés SSH d'un utilisateur [2] :

Si vous avez plusieurs ordinateurs, le mieux est de générer une clé pour chacun et d'ajouter les différentes clés à la forge utilisée.

[1] Sous Windows 10, le fichier de niveau utilisateur .gitconfig se trouve dans C:\Users\nom_user\.

[2] Pour Github ou BitBucket des interfaces similaires sont disponibles.

Installation de Git

_Eric_ — 2019-12-14T13:20:36Z

Sommaire

Introduction

Il existe un tutoriel très complet sur le site de Atlassian qui décrit les différentes possibilités pour installer Git sur son ordinateur et ce, pour les différents systèmes d'exploitation. Le but de ce chapitre n'est donc pas de reprendre l'ensemble des informations du tutoriel d'Atlassian mais d'apporter des précisions.

Le tutoriel d'Atlassian est donc à lire en préambule pour le système d'exploitation qui vous concerne.

Sous Windows

Lien tutoriel : https://www.atlassian.com/fr/git/tutorials/install-git#windows.

La meilleure solution sous Windows est d'installer le logiciel « Git for Windows » disponible sur le site https://gitforwindows.org/. Il suffit de télécharger la dernière version disponible et de lancer l'exécutable d'installation. Pour la version 2.25.0 la séquence des fenêtres de configuration est un peu longue et parfois un peu obscure. Elle est rappelée et expliquée ci-dessous :

En premier lieu il faut choisir les composants à installer. Le Bash est essentiel, le GUI est inutile (à mon avis) et peut être avantageusement remplacé par un autre GUI comme expliqué dans l'article Installation et configuration d'un GUI : SourceTree. On peut donc le décocher.

On choisit ensuite son éditeur par défaut, qui servira pour saisir les messages de commits, ici Notepad++.

Le troisième étape est cruciale. Si on ne veut jamais utiliser autre chose que le Git Bash qui va être installé (c'est-à-dire l'invite de commande) on peut cocher le premier choix. Si on veut utiliser un GUI comme SourceTree alors il faut cocher le deuxième choix (comme sur l'image) et « Git for Windows » s'occupe seul de créer le bon environnement pour cela. En général, il n'y a pas lieu de faire un autre choix.

L'étape 4 est aussi délicate. Si vous cochez le premier choix il vous faudra... je ne sais plus quoi mais c'est chiant !!!.

Pour l'étape 5 le premier choix est recommandé (lire l'explication).

Il reste encore 3 étapes qu'il suffit de valider en laissant le choix par défaut et le processus de configuration se termine. Une fois l'installation complète terminée vous disposez d'un Git utilisable avec votre une ligne de commande Bash et éventuellement d'un GUI minimal.

Le menu contextuel de l'explorateur s'est enrichi d'un item « Git Bash Here » qui permet d'ouvrir une fenêtre Bash dans le répertoire choisi ce qui est bien pratique.

Sous Mac OS

Lien tutoriel : https://www.atlassian.com/fr/git/tutorials/install-git#mac-os-x.

Plusieurs possibilités s'offrent à vous :

Xcode ou uniquement ses outils ligne de commande ;
le logiciel « Git for Mac » à l'instar de Windows ;
avec Homebrew ;
ou avec MacPorts.

Si vous avez installé Xcode ou ses outils CLI vous pouvez utiliser Git nativement, l'environnement ayant été mis au point. Git est installé dans /usr/bin et inclut dans le PATH par défaut.
La commande git --version permet de consulter la version Git installée et on reconnait le fork de Apple grâce à une indication entre parenthèses.

Sinon, l'autre solution est à l'instar de Windows, d'installer « Git for Mac » que l'on peut trouver à l'adresse https://sourceforge.net/projects/gi.... Ce logiciel installe Git dans /usr/local/git et des liens symboliques sont créés dans /usr/local/bin. Pour utiliser cette installation de Git il faut donc rajouter le dossier /usr/local/bin dans le PATH.

Il est possible de concilier ces deux installations et de passer de l'une à l'autre en ajoutant ou supprimant le dossier /usr/local/bin du PATH. Cela peut être nécessaire si on veut faire du Git-SVN qui n'est plus embarqué dans « Git for Mac ».

Sous *NIX

Lien tutoriel : https://www.atlassian.com/fr/git/tutorials/install-git#linux.

Objectif et contenu du guide Git

_Eric_ — 2019-12-14T13:20:18Z

Le présent guide a pour but de rassembler les liens vers des ressources Git et de les compléter en fournissant des explications plus détaillées ou plus accessibles sur certains sujets, en particulier, pour les utilisateurs non aguerris.

Le guide est organisé en plusieurs articles :

Installation de Git, décrit les différentes méthodes d'installation de Git sur Windows, MacOS et *NIX ;
Configuration de Git, qui explique quelle configuration minimale est nécessaire pour utiliser ou simplifier l'utilisation de Git ;
Les bases de l'utilisation de Git, liste des ressources de démarrage et rappelle les principales notions de Git ainsi que commandes usuelles ;
Tutoriel de démarrage avec Git, fournit un tutoriel de démarrage avec Git basé sur des cas d'usage très simples ;
Installer un SPIP en Git, qui explique comment installer un nouveau site SPIP ou migrer un environnement SPIP en Git ;
Comprendre la forge Git de SPIP ;
Utiliser la forge Git de SPIP pour contribuer ;

Il existe des tas de pages sur Git et son utilisation. Néanmoins, toutes ne sont pas accessibles pour les utilisateurs débutants ou occasionnels. Par contre, des ressources se révèlent très utiles à tous :

ProGit, le livre de Scott Chacon et Ben Straub, disponible en version web française et anglaise à l'adresse https://git-scm.com/book/fr/v2. Ce livre s'inscrit dans un site plus large qui comprend aussi une référence Git, des tutoriels vidéo et des liens externes vers d'autres ressources Git. Ce site a largement inspiré certains articles du présent guide.
les tutoriels Git de l'éditeur Atlassian.
et bien entendu la documentation officielle.

Dans la suite du guide, d'autres ressources plus spécifiques seront identifiées car leur lecture est nécessaire à la compréhension du guide.

La Taverne à Tonton

Isocode, structure du plugin

Sommaire

Les ressources ISO pour les langues

Les ressources IANA

Les ressources ISO pour les subdivisions

Les ressources ISO des pays

Les codes ISO

Les traductions additionnelles

Les ressources GEONAMES

Les ressources GEOIP

Les ressources UN M49 des régions du monde

Fichier M49regions.csv

Fichier M49regions_countries.csv

Récapitulatif des modifications proposées

Sommaire

Introduction

Modifier la liste des langues

Nouvelle gestion de la liste des langues

Adaptation du code de SPIP

Traduction des noms de langue

Renommage des fichiers de langue

Mise à jour de TradLang

Mise à jour de Smart-Paquets

Git avancé

Sommaire

Utiliser git pour pusher les mises à jour vers un site en production

Principe :

Sur le serveur cible :

En local

Installer un SPIP en Git

Sommaire

Introduction

L'outil checkout

Prérequis

Installation de la distribution officielle de SPIP

L'outil git_loader

Prérequis

Installation de la distribution officielle de SPIP

Installer un jeu de plugins

Migrer un SPIP existant

FAQ Git pour SPIP

Tutoriel de démarrage avec Git

Sommaire

Introduction

Initier un dépôt Git local

Initier un dépôt à partir d'un répertoire vide

Cloner un dépôt distant

Consigner les modifications du dépôt local

Ajouter un fichier au dépôt Git

Modifier un fichier suivi par Git

Supprimer un fichier suivi par Git

Pousser les modifications locales sur un dépôt distant

Les bases de l'utilisation de Git

Sommaire

Introduction

Liens d'apprentissage et de référence

Notions de base de Git

Une gestion d'instantanés

Une gestion locale

Des zones et des états

Dépot local et dépot distant

Commandes Git de base

Configuration de Git

Sommaire

Principes de base

Configuration classique au niveau utilisateur

Configuration des fichiers ignorés

Configuration des droits d'accès

Installation de Git

Sommaire

Introduction

Sous Windows

Sous Mac OS

Sous *NIX

Objectif et contenu du guide Git

Fichier `M49regions.csv`

Fichier `M49regions_countries.csv`