Commit 243a1b41 authored by Antoine Fauchié's avatar Antoine Fauchié

edit: nouveau billet sur l'intérêt de Git dans la gestion de contenu

parent b8b11d70
---
layout: post
title: "Pourquoi gérer du contenu avec Git ?"
date: 2018-06-10 08:00
comments: true
published: true
description: "Pourquoi utiliser Git pour gérer du contenu, plutôt qu'un CMS ?
Voilà, en quelques points, une esquisse de réponse à la question posée par Nicolas.
Il est question de versionnement, de déploiement, de fichiers texte et de hub.
Ce billet, très imparfait, ne mérite que d'être précisé et complété!"
categories:
- carnet
---
Pourquoi utiliser Git pour gérer du contenu, plutôt qu'un CMS ?
Voilà, en quelques points, une esquisse de réponse à la question posée par Nicolas.
Il est question de versionnement, de déploiement, de fichiers texte et de hub.
Ce billet, très imparfait, ne mérite que d'être précisé et complété !
<!-- more -->
À l'occasion de mon précédent billet concernant l'ouverture du dépôt Git d'un mémoire en cours d'écriture, [Nicolas s'interroge](https://twitter.com/nicolastilly/status/1005429681305346048) sur l'usage de Git pour du texte.
Qu'est-ce que Git peut apporter de plus par rapport à une gestion via un gestionnaire de contenu (CMS) web&nbsp;?
Réponse en quelques points&nbsp;:
1. Un système de gestion de contenu – ou CMS – oblige à utiliser une interface web, sous-entendu un outil est imposé.
Rares sont les CMS à proposer des APIs permettant de connecter d'autres interfaces ou applications.
Personnellement j'aime beaucoup écrire dans un éditeur de texte&nbsp;: je n'ai pas besoin de me soucier de la connexion internet, je peux changer d'éditeur et son aspect sans que cela n'ait d'incidence sur le processus.
C'est ce que j'avais tenter d'expliquer [ici](/2012/12/23/pourquoi-quitter-wordpress/).
2. Premier bonus&nbsp;: il est possible d'écrire avec un langage de balisage léger comme Markdown, la structure du document n'est pas dépendante d'un éditeur en mode WYSIWYG (What You See Is What You Get).
3. Deuxième bonus&nbsp;: Git permet de conserver une version locale du projet, c'est le cas également pour les autres intervenants – s'il y en a.
Il n'y a pas de dépendance à une plate-forme – quand bien même une instance de WordPress serait par exemple installé sur un serveur personnel –, et les fichiers source ne sont ni dans des formats incompréhensibles par nous les humains, ni dans des bases de données.
4. Git versionne les fichiers&nbsp;: les évolutions d'un projet peuvent être suivies en sachant qui (personne/rôle) à fait quoi (fichiers modifiés) et où (version/branche du projet).
À cela on peut opposer le fait que beaucoup de gestionnaire de contenus ont adopté ce fonctionnement – comme [Google Docs](https://github.com/google/diff-match-patch) par exemple –, mais c'est un procédé très limité et enfermé dans le gestionnaire.
5. Git est une machine à voyager dans le temps&nbsp;: on peut revenir en arrière sans tout casser.
Certes ce n'est pas forcément toujours simple – surtout en ligne de commande – mais c'est _possible_&nbsp;!
6. Un dépôt Git peut être hébergé par des plate-formes et être visualisé avec des interfaces web.
Par exemple GitLab ou GitHub permettent de gérer des projets Git, et de faire toutes les interventions habituelles dans Git, plus _d'autres choses_.
7. Ce "d'autres choses" est très intéressant&nbsp;: par exemple la gestion d'issues (tickets pour signaler des bugs ou des erreurs) en lien avec Git (issue liée à une branche), ou des interfaces qui rendent des commandes plus compréhensibles que via un terminal.
8. Toujours à partir de Git et d'une plate-forme en ligne, il est possible d'automatiser des actions.
Exemple&nbsp;: à chaque fois que je fais un commit (un enregistrement) dans la branche master (la version principale du projet), des fichiers sont envoyés sur un serveur web.
9. En terme d'organisation cela veut dire que l'on peut tester des choses dans une branche parallèle, et quand c'est validé, passer sur master et les fichiers seront automatiquement envoyés sur un serveur.
Pratique pour gérer et tester un site web 😉
C'est ce qu'on appelle le [déploiement continu](https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/).
10. Ce principe peut aller plus loin&nbsp;: à chaque commit sur une branche les fichiers Markdown vont être transformés en fichiers HTML grâce à un générateur de site statique, tout cela étant généré via une machine virtuelle.
11. On peut imaginer beaucoup plus d'usages&nbsp;: par exemple avec [Thomas](https://oncletom.io) nous nous sommes amusés à générer un fichier .docx à partir d'un fichier AsciiDoc, avec une bibliographie en bibtex et une feuille de style Word 😎
12. Ces actions automatisées peuvent également être des tests, différents selon des branches définies (beta, preprod, etc.).
C'est ce qu'on appelle l'[intégration continue](https://rpadovani.com/introduction-gitlab-ci).
13. Dans le cas des générateurs de site statique il y a même des services qui viennent se connecter à notre dépôt Git pour que l'on puisse gérer les contenus directement en ligne, avec des interfaces dignes d'un CMS.
C'est le cas de [Forestry.io](https://forestry.io/)&nbsp;: "Your editing team won’t even realize they’re editing Markdown and committing to your repo."
14. Toujours dans le cas des générateurs de site statique, d'autres services peuvent gérer le déploiement du site web, c'est le cas de [Netlify](https://www.netlify.com/).
15. Donc il faut voir Git comme un hub auquel viennent se connecter tout un tas de services.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment