Commit 59b066a2 authored by Antoine Fauchié's avatar Antoine Fauchié

edit: reformulations à la marge et suppression de répétitions

parent 243a1b41
---
layout: post
title: "Pourquoi gérer du contenu avec Git ?"
date: 2018-06-10 08:00
date: 2018-06-10 10:00
comments: true
published: true
description: "Pourquoi utiliser Git pour rer du contenu, plutôt qu'un CMS ?
description: "Pourquoi utiliser Git pour administrer 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é!"
Ce billet, très imparfait, ne mérite que d'être précisé et complété !"
categories:
- carnet
---
Pourquoi utiliser Git pour rer du contenu, plutôt qu'un CMS ?
Pourquoi utiliser Git pour administrer 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.
À l'occasion de [l'annonce](/2018/06/04/un-memoire-en-depot/) de l'ouverture du dépôt Git de mon 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.
1. Un système de gestion de contenu – ou CMS – oblige à utiliser une interface web, ce qui signifie qu'un outil est imposé.
Rares sont les CMS à proposer des APIs permettant de connecter d'autres interfaces ou applications – ou alors de façon unilatérale.
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 modifier 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).
2. Premier bonus&nbsp;: écrire avec un langage de balisage léger comme Markdown est alors la meilleure approche, 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.
......@@ -39,27 +39,29 @@ Il n'y a pas de dépendance à une plate-forme – quand bien même une instance
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_.
GitLab, GitHub ou Gitbucket sont les plus populaires, elles permettent de manier des projets Git, et apportent la possibilité de faire toutes les interventions habituelles via une interface web, 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 rer et tester un site 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 administrer 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.
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, les différents programmes fonctionnant sur 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.
13. Dans le cas des générateurs de site statique il y a 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/).
14. Toujours dans le cas des générateurs de site statique, d'autres services peuvent se charger de déployer le 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.
15. Il faut voir Git comme un _hub_ auquel viennent se connecter différents services.
Les propositions de modification de cette liste sont bienvenues&nbsp;!
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