SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano | Nederlands

286 Plugins, 197 contribs sur SPIP-Zone, 246 visiteurs en ce moment

Accueil > Documentation > Tutoriels pour webmasters > Gérer le développement de son site avec Git

Gérer le développement de son site avec Git

17 mars 2010 – par davux – commentaires

11 votes

Quand on développe un site web, il peut être utile d’utiliser un gestionnaire de révisions. Personnellement, j’utilise git. Cet article explique donc comment tirer parti de cet outil pour gérer vos modifications successives, et surtout les mises à jour de SPIP, le tout proprement.

Cet article n’est pas un comparatif entre git et Subversion (svn), qui reste le gestionnaire de révisions utilisé pour développer SPIP lui-même ainsi que les différents plugins trouvables sur SPIP-Zone [1].

Préambule

Il faut d’abord avoir git d’installé. Suivant votre système, ça varie, et d’autres l’ont déjà documenté par ailleurs, alors je vous laisse faire.

Ce tuto explique comment gérer votre site SPIP avec git dès le début. Bien que je donne les commandes à taper et tente de les rendre compréhensibles, cet article n’est pas un tutoriel git . Je vous conseille donc de vous familiariser au moins avec les principes de base ainsi qu’avec les principales commandes.

J’explique ici comment faire au moyen de la commande git sous Linux. Cependant, il existe diverses autres interfaces, y compris des interfaces graphiques du même genre que TortoiseSVN [2]. La méthodologie reste la même.

Pour cet exemple, on se place dans le scénario d’une installation fraîche de SPIP 2.0.10 en local, puis d’une mise à jour vers la future version 2.1.0. Idem, les versions peuvent changer, c’est la même méthodologie.

Ce tuto s’intègre très bien dans la stratégie de développement suivante :
-  L’installation de SPIP ainsi que le travail de développement sont faits en local.
-  Quand l’état actuel est satisfaisant, synchroniser le tout sur le site distant réel.
-  Continuer à travailler en local, etc.

Note aux personnes habituées à SVN et CVS : Pour la suite du tuto, il est très important de garder en tête que dans git, un commit n’est pas un commit vers un serveur central situé sur internet. Il s’agit simplement d’un enregistrement en local d’un ensemble de modifications. Les envois sur le réseau (push) sont une opération indépendante.

Import initial des fichiers de SPIP

  1. Décompresser le .zip de SPIP 2.0.10 dans le répertoire de votre choix.
  2. Se placer dans le répertoire et initialiser le dépôt git :
    git init
  3. Ajouter le répertoire actuel au gestionnaire de révisions, et committer les changements :
    1. git add .
    2. git commit -m 'Import de SPIP 2.0.10'
  4. On est sur la branche master. Nous, stratégiquement, on va garder notre SPIP standard (des fois on dit "upstream" en anglais) sur sa propre branche, en prévision des futures mises à jour. Malin ! Pour cela, on va renommer la branche master en spip_upstream (ou autre) :
    git branch -m spip_upstream
  5. Enfin, pour pouvoir continuer notre travail proprement, on crée une nouvelle branche master, et on bascule dessus :
    git checkout -b master

Les fichiers de SPIP sont maintenant prêts, et le contexte de git est posé !

PNG - 31.6 ko
Contexte git posé
Les fichiers de SPIP 2.0.10 ont été importés, et nos 2 branches sont là.

À ce stade, il est nécessaire de comprendre que nous avons créé 2 branches distinctes :
-   spip_upstream contient le code de SPIP "standard", tel que disponible sur internet. Le dernier commit est celui qu’on vient de faire, jusqu’à la prochaine version de SPIP.
-   master est basée sur spip_upstream, mais va avancer avec vos développements propres en tant que webmaster.

À tout moment, vous pouvez visualiser les branches existantes, et également savoir sur laquelle vous vous trouvez, grâce à la commande git branch. L’outil gitk est également un excellent moyen d’avoir une représentation graphique des commits et des branches.

Finaliser l’installation

Au cours de sa vie, à commencer par l’installation, SPIP manipulera automatiquement des fichiers dans certains répertoires : son cache, des logs, etc. On ne veut évidemment pas inclure ces fichiers dans le suivi de révisions.

Par ailleurs, les fichiers du répertoire IMG/ (logos des articles, documents joints, logo du site, etc.) sont aussi probablement à exclure du suivi de révisions. Ces fichiers concernent le contenu éditorial du site et non son code. Comme pour la base de données, il est donc préférable d’utiliser une méthode de sauvegarde appropriée, indépendante de votre travail sur le code du site.

Pour informer git qu’il ne doit pas suivre les modifications de ces répertoires, on va créer un fichier nommé .gitignore, contenant les noms des fichiers et répertoires à ignorer :

Par ailleurs, vous n’avez pas forcément envie que les données d’accès à la base soient visibles et sauvegardées dans l’historique de git. En particulier dans le cas d’une installation en local et d’export vers un autre site via la commande git push [3], les données de connexion à la base seront probablement différentes d’une instance à l’autre du site. Dans ce cas, il peut être sensé d’ajouter config/connect.php à votre fichier .gitignore pour qu’il ne soit pas pris en compte par git.

Enfin, optionnellement, si cette liste de fichiers à ignorer est spécifique à votre installation locale et qu’elle perdrait son sens sur une autre instance du site (ça, c’est à vous de voir), vous pouvez mentionner .gitignore lui-même dans le fichier. Sinon, vous pouvez très bien l’intégrer au suivi de révisions.

Une fois le fichier .gitignore sauvegardé, si vous ne l’avez pas inclus dans sa propre liste de fichiers à ignorer, c’est une bonne idée de committer le changement :

  • git add .gitignore
  • git commit -m "Ignorer les fichiers temporaires de SPIP"

En parallèle à ça (avant, après, ou avec l’autre main), terminez votre installation de SPIP (c’est expliqué là, chapitre « Terminer l’installation ») avec le navigateur. Les seuls fichiers modifiés seront ceux qu’on vient de demander à git d’ignorer, donc aucun autre mouvement ne sera généré dans votre dépôt.

Travail sur votre site

Là, c’est le moment du film où vous commencez à travailler sur votre site (allez, au travail !), typiquement en éditant des squelettes et les CSS, en installant des plugins, en envoyant tout ça sur internet... Bref, faire le site, quoi. Allez-y, on vous regarde.

Maintenant que vous utilisez un gestionnaire de révisions, et que vous êtes sur la branche master, après chaque modification intelligente et assumée, vous pouvez (devez) committer. On s’y fait. Ça reste en local ; à chaque fois que vous atteignez un état satisfaisant dans votre code, vous pouvez l’envoyer sur le site distant réel (avec git push ou FTP, voir dernier paragraphe).

Répétez le paragraphe précédent en boucle, jusqu’à ce que l’équipe de SPIP sorte une nouvelle version. N’oubliez pas de boire et manger entre temps.

Une nouvelle version de SPIP est sortie

Jour de fête, une nouvelle version de SPIP vient de sortir !

Committer ce qui ne l’est pas encore, et aller chercher une coupe de champagne et une part de gâteau. Avant d’avoir trop bu, revenir, trouver la chaise, puis l’écran. Enfin, localiser le clavier et se concentrer sur les étapes suivantes. (En cas d’échec, retourner avec les autres et continuer le tuto le lendemain.)

Import de la nouvelle version de SPIP

PNG - 1.8 ko
État des branches après import 2.1.0
Fin de l’étape 4 : On visualise bien les différents commits, et les deux branches distinctes. Master est à l’état où on a laissé le développement du site au moment du début de la mise à jour.
  1. Basculer vers la branche de "SPIP nu" :
    git checkout spip_upstream
  2. Supprimer tous les fichiers de la version 2.0.10 (mais pas le répertoire .git !), et les remplacer par les nouveaux. Vous pouvez utiliser git status et git diff pour voir les nouveautés.
  3. Tout ajouter :
    git add .
  4. Committer, comme la première fois (noter cependant le -a pour tout prendre en compte, y compris les suppressions) :
    git commit -a -m 'Import de SPIP 2.1.0'
    C’est enregistré, git status vous dit que tout est clean.
  5. On est toujours dans la branche spip_upstream, contenant maintenant un SPIP 2.1.0 "nature". Créer une branche de transition et basculer dessus :
    git checkout -b spip_maj_vers_2.1.0
  6. Fusionner l’état actuel de notre code (branche master) avec la nouvelle version :
    git merge master

À partir de là, on est toujours dans la branche de transition, car le travail n’est pas fini, mais on a un SPIP mis à jour en 2.1.0.

La ruse de la branche de transition, c’est qu’on va pouvoir faire notre salade dedans, se planter, faire des essais, préparer le site nickel pour la 2.1, et seulement quand ça sera prêt, ramener tout ça sur la branche master. Comme ça, pendant ce temps, on garde un master clean, en 2.0.10 qui marche. Si vous avez l’habitude d’utiliser CVS ou subversion, cet usage des branches peut vous surprendre. Une particularité de git est que le coût d’une nouvelle branche est quasi nul : une branche n’est qu’un "pointeur" sur un commit donné. On peut donc les utiliser à tout bout de champ comme des "marque-page".

Si les étapes précédentes ne sont pas très claires, une astuce est de bien garder en tête à chaque étape dans quelle branche on se situe (c’est le même principe que les répertoires et la commande cd). En cas de doute, pensez à vos amies : la commande git branch, et l’interface graphique gitk. Sinon, c’est peut-être le champagne.

PNG - 2.6 ko
Branche de transition créée, master fusionnée.
Fin étape 6 : On est (en gras) sur la branche de transition créée à partir de spip_upstream, et on lui a intégré la branche master. Comparez avec le screenshot précédent si ce n’est pas clair. Le changement d’emplacement vertical de spip_upstream ne compte pas, seuls les liens comptent.

La partie artistique, alias "ce pour quoi on vous paie"

Maintenant, il reste le plus important, qui dépend complètement de vos squelettes, des versions de SPIP considérées, et de vos talents de webmaster : adapter votre code à la nouvelle version de SPIP. Puisque vous avez probablement configuré votre site en local, l’heure est au vidage de cache, à la mise à jour de la base (voir doc, étape 3) sur le site local, et aux tests jusqu’à ce que ça marche. Cette partie inclut le remplacement des anciens plugins par les nouveaux, bref tout ce qu’il faut pour que le site marche nickel en local.

-  Note 1 : N’oubliez pas de committer chaque changement proprement.
-  Note 2 : Si vous avez configuré un ou des dépôts distants, que ce soit le site lui-même ou autre, vous pouvez même pusher vos changements : on est sur la branche de mise à jour, donc pas de souci, master est toujours inchangé.

Bon, je vous laisse bosser, on me fait signe qu’il reste du gâteau.

PNG - 3.1 ko
Travail d’adaptation des squelettes terminé
Les commits successifs d’adaptation des squelettes font simplement avancer la branche de travail. La branche master représente toujours le site avant migration, et l’upstream attend sagement la prochaine version de SPIP.

Voilà. Là, vous avez donc un site rutilant en local, et tout est commité, git status est content. On n’a plus qu’à boucler tout ça.

Boucler tout ça

  1. Rebasculer fièrement vers la branche master, avec des airs de « Chéri(e), j’ai une surprise pour toi ».
    git checkout master
  2. Ramener le fruit de notre (votre) travail :
    git merge spip_maj_vers_2.1.0
  3. Supprimer la branche de transition, maintenant qu’elle est totalement intégrée :
    git branch -d spip_maj_vers_2.1.0
PNG - 3.2 ko
On a fusionné la branche de mise à jour avec master
Fin étape 2 : On est sur master, et la branche est fusionnée avec maj. Comme master était « ancêtre » de maj, la fusion fut facile pour git (fast-forward) : master pointe maintenant sur le même commit que maj.

Et voilà, on est à jour, et en master ! Plus qu’à envoyer sur le site réel. Avant cela, n’oubliez pas l’étape 1 (sauvegarde de précaution) du tuto habituel. C’est une bonne idée de désactiver les plugins du site, aussi, car certains vont être supprimés. Quand l’envoi est effectué, passez directement à l’étape 3 (mise à niveau de la base). Les nouveaux plugins sont arrivés avec le déménagement, il n’y a plus qu’à les réactiver. Un petit vidage de cache par-dessus tout ça, et listo !

Que faire en cas de modification manuelle du code de SPIP ?

Dans la vraie vie, c’est parfois plus compliqué : par exemple, entre deux versions stables, une alerte de sécurité est donnée, et un correctif fourni. Ou bien, vous voulez absolument modifier le code de SPIP parce que vous avez la certitude (vous vous trompez) que dans ce cas précis vous ne pouvez pas passer par ces mécanismes merveilleux que sont les plugins, les pipelines, les surcharges de fonctions, etc. Autre cas de figure, vous avez vu passer un commit trop bien sur la version de dev, et ça vous emballe tellement que vous ne pouvez pas attendre la prochaine version et vous décidez de modifier le code de SPIP pour appliquer ce changement.

Dans ces cas, il faut au moins faire ça bien, sinon à la prochaine mise à jour de SPIP, git va hurler au conflit. Rassurez-vous, c’est simple. Mais il faut faire ça bien.

PNG - 3.8 ko
Patch appliqué
On a fait avancer spip_upstream d’un cran vers le haut avec notre correctif, et on a ramené l’upstream tout neuf dans master. Pareil, comparez avec la capture précédente pour bien saisir ce qui s’est passé.
Attention : gitk montre maintenant les commits du site à gauche, en ligne droite, et l’upstream à droite, mais souvenez-vous : seuls les liens comptent.
  1. Committer ce qui ne l’est pas encore, comme d’hab.
  2. Basculer sur la branche spip_upstream :
    git checkout spip_upstream
  3. Faire votre cuisine dans le code.
  4. Committer chaque changement proprement.
  5. Rebasculer sur la branche de travail :
    git checkout master
  6. Intégrer le nouveau spip_upstream :
    git merge spip_upstream

Le piège (ça m’est arrivé), c’est de ne pas basculer vers spip_upstream pour faire les changements, mais les faire directement dans master. Mauvaise idée : à la prochaine mise à jour, ça va être pénible à dépatouiller. Vous modifiez SPIP, vous le faites dans la branche de SPIP, picétou.

Après la prochaine mise à jour de SPIP, bien sûr, n’oubliez pas d’appliquer de nouveau vos changements si besoin [4]. Si c’était un patch de sécurité, pas la peine, il sera évidemment compris dans la nouvelle version. Si c’était un changement "maison", vraiment, faites un plugin, ou bien proposez votre amélioration sur la liste spip-dev@rezo.net. Ça évitera de maintenir votre propre version de SPIP en parallèle, et ça servira sûrement à d’autres.

Amélioration possible : utiliser git pour publier ses modifications

A priori, comme expliqué au début, vous travaillez toujours sur une copie du site installée en local, et à chaque fois que ça semble bien, vous envoyez tout ça sur le site réel.

Pour cela, il y a bien entendu l’option classique d’envoyer le tout via FTP, SSH, ou autre, en remplaçant tous les fichiers du site actuel par les nouveaux.

Cependant, une utilisation très intéressante de ce qu’on vient de mettre en place, c’est que vous pouvez utiliser git push pour envoyer vos changements vers le site en production. Ainsi, vous n’avez même pas besoin de tout effacer et remplacer à chaque fois : seules les différences seront envoyées. Une autre destination peut être un dépôt de type GitHub, Gitorious, ou même votre propre dépôt sur une autre machine. Il s’agit cependant là d’un tout autre chapitre, qui sera probablement détaillé dans un prochain article.

Notes

[1Il existe cependant divers moyen d’obtenir le code de SPIP et de SPIP-Zone via git.

[2Moi j’aime bien gitk.

[3Cet aspect ne sera pas détaillé dans cet article, car c’est un sujet à part.

[4Si vous avez bien documenté vos changements en temps et en heure, les commandes git log et git diff premier-hash second-hash vous permettront de les retrouver.

Dernière modification de cette page le 7 novembre 2011

Retour en haut de la page

Vos commentaires

  • Le 27 février 2012 à 01:41, par Oliv En réponse à : Gérer le développement de son site avec Git

    @davux : comme Mat C. je serais super*10^(x+1) intéressé par la suite du tuto.
    On veut la suite de l’histoire… :-)

    Répondre à ce message

  • Le 7 novembre 2011 à 22:42, par ibenot En réponse à : Gérer le développement de son site avec Git

    « Cependant, une utilisation très intéressante de ce qu’on vient de mettre en place, c’est que vous pouvez utiliser git push pour envoyer vos changements vers le site en production. Ainsi, vous n’avez même pas besoin de tout effacer et remplacer à chaque fois : seules les différences seront envoyées. Une autre destination peut être un dépôt de type GitHub, Gitorious, ou même votre propre dépôt sur une autre machine. Il s’agit cependant là d’un tout autre chapitre, qui sera probablement détaillé dans un prochain article. »
    Cet article a t-il été rédigé ?! ^^
    merci

    • Le 7 novembre 2011 à 22:48, par davux En réponse à : Gérer le développement de son site avec Git

      Non... Personnellement j’attends qu’on ait une solution qui plaise à tou·te·s les dev core niveau git pour faire un tuto adapté spécifiquement à l’utilisation de git avec SPIP. Km bosse dessus actuellement, je crois.

    • Le 27 décembre 2011 à 02:06, par Oliv En réponse à : Gérer le développement de son site avec Git

      Ho, voilà qui m’intéresse énormément !!! ;-)
      Des brouillons de ce travail sont-ils consultables ? Merci.

    Répondre à ce message

  • Le 18 décembre 2011 à 13:50, par Mat C. En réponse à : Gérer le développement de son site avec Git

    ARg !!! J’suis méga frustré, moi ce qui m’intéresse c’est de pouvoir envoyer mon site commité vers mon serve, mais git push me résiste ! J’imagine que c’est parce que je ne maitrise pas la bête (m’y suis mis hier...) mais du coup le tuto annoncé dans le dernier paragraphe m’intéresse au plus haut point !
    « ou même votre propre dépôt sur une autre machine. Il s’agit cependant là d’un tout autre chapitre, qui sera probablement détaillé dans un prochain article. »
    As-tu eu le temps de te coller à ce tuto ? Pourrais-je avoir un lien ?

    Merci en tout cas pour cette présentation d’une utilisation de git pour webmaster :)

    Répondre à ce message

  • Le 7 novembre 2011 à 22:53, par ibenot En réponse à : Gérer le développement de son site avec Git

    ah ! merci en tout cas pour cette rapidité, et bonne chance pour la rédaction et encore bravo pour le ton « humoristique » du tuto.... je file il reste du gateauuuuuu
    bye

    Répondre à ce message

Répondre à cet article

Qui êtes-vous ?
  • [Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Ajouter un document

Retour en haut de la page

Ça discute par ici

  • Metas +

    3 décembre – commentaires

    Améliorez l’indexation de vos articles dans les moteurs et leur affichage sur les réseaux sociaux grâce aux métadonnées Dublin Core, Open Graph et Twitter Card. Installation Activer le plugin dans le menu dédié. Dans le panel de configuration, (...)

  • Critère {mots}

    6 août 2009 – 316 commentaires

    Permettre de sélectionner facilement des objets SPIP ayant un ou des mots clefs en communs.

  • LinkCheck : vérificateur de liens

    13 février 2015 – 64 commentaires

    Ce plugin permet de chercher et tester l’ensemble des liens présents dans les objets. Vous pourrez donc en quelques clics connaître les liens brisés ou défectueux qui se sont immiscés dans le contenu de votre site SPIP. La vérification s’effectue en (...)

  • Import ICS 2 (agenda distant)

    2 août – 39 commentaires

    La version 2 du plugin « import ICS » en reprend la principale fonctionnalité, à savoir l’ajout automatique d’évènements distants dans la liste des évènements d’un site. À la différence de la première version, elle ne dépend pas du plugin « Séminaire » et est (...)

  • GIS 4

    11 août 2012 – 1286 commentaires

    Présentation et nouveautés La version 4 de GIS abandonne la libraire Mapstraction au profit de Leaflet. Cette librairie permet de s’affranchir des librairies propriétaires tout en gardant les mêmes fonctionnalités, elle propose même de nouvelles (...)