Sauvegarder et partager son historique git

samedi 28 novembre 2015, mise à jour mardi 20 mars 2018, par Maïeul
Suivre la vie du site RSS 2.0 Forum

Il y a fort, fort longtemps, j’ai écrit une petite introduction à Git pour expliquer à un.e chercheur.euse utilisant LaTeX comment versionner son travail. Je poursuis ici, en expliquant comment envoyer son historique Git sur un serveur, afin d’avoir d’une part une copie de sauvegarde, et d’autre part de pouvoir travailler avec d’autres personnes.

Objectifs

Contentons-nous d’objectifs simples :

  • ouvrir un dépôt git distant
  • y envoyer une copie de notre dépôt local
  • mettre régulièrement à jour cette copie
  • la récupérer depuis un autre ordinateur et faire la synchronisation

Principes de base

Avec Git, l’historique du travail est conservé sur l’ordinateur de travail, dans ce qu’on appelle un dépôt git. Il est cependant possible de créer un dépôt git sur un autre ordinateur, et de le synchroniser avec notre propre dépôt. Les avantages sont évidemment multiples :

  • pour la personne qui travaille sur une seule machine, avoir un copie de sauvegarde en plus de celle de sa machine.
  • pour la personne qui travaille sur plusieurs machines, pouvoir synchroniser les historiques entre les machines
  • pour les personnes qui travaillent sur le même projet, pouvoir se synchroniser.

Nous allons prendre un cas simple :

  • deux dépôts locaux de travail : (A) et (B)
  • un dépôt distant de synchronisation et sauvegarde (C)
Utiliser un serveur pour synchroniser ses historiques git

XX travaille sur (A). Il y enregistre l’historique de ses modifications. À la fin de sa session de travail, il les envoie sur (C). Au début de sa session de travail, YY récupère l’historique depuis (C) et le met sur (B). À la fin de sa session, il envoie ses modifications sur (C). Quand XX reprend le travail, il récupère depuis (C) vers (A), puis envoie sur (C) ses nouvelles modifications à la fin de sa session, etc.

Je prends un cas simple dans la mesure où je suppose que chaque personne récupère l’historique sur (C) avant de travailler, et renvoie son historique à la fin de son travail. En outre XX et YY ne travaille pas en parallèle. Si bien lorsqu’on travaille tant sur (A) que sur (B), on a forcément tout ce qui existe déjà sur (C).

Git permet de gérer les cas où XX récupère l’historique sur (C) pour le mettre en (A), et pendant qu’il travaille YY envoie des données sur (B). Cependant, je n’aborderai pas, ici en tout cas, ce problème.

Il permet également de travailler avec plusieurs dépôts distants, mais une chose à la fois.

Communication entre les dépôts

Puisque les données de (A) (et de (B)) doivent être envoyées vers le dépôt (C), il nous faut :

  • Savoir où se trouve le dépôt (C), autrement dit connaître son adresse. Très souvent l’adresse d’un dépôt distant est de la forme git@serveur:utilisateur/nom.git.
  • référencer ce dépôt distant depuis le dépôt local. Comme il est possible de lier un dépôt local à plusieurs dépôts distants (remote), chaque adresse de dépôt distant se verra ajouter un alias. Pour notre cas, nous allons utiliser un seul dépôt distant, dont l’alias sera « origin », un terme conventionnel.
  • faire quelques petits réglages pour permettre à votre ordinateur de communiquer avec l’ordinateur sur lequel se trouve le dépôt de manière sécurisée et authentifiée.

Création et réglage d’un compte chez Framasoft

Choix de Framasoft

N’importe quel serveur ayant une installation Git peut héberger un dépôt Git distant. Il vous est donc possible de demander à une institution de rattachement (Université, Centre de Recherche). Il existe cependant des structures proposant non seulement des dépôts Git, mais aussi des interfaces graphiques pour les gérer et d’autres outils.

La plus célèbre de ces structures est l’entreprise Github. Pour ma part, je vous proposerai d’utiliser les services de l’association Framasoft, pour diverses raisons :

  • pour éviter de concentrer l’internet en quelques pôles, le plus souvent privés.
  • parce que Framasoft est une association, et non une entreprise.
  • parce que l’infrastructure proposée tourne sous logiciel libre, et que vous pourrez vous même monter un jour votre propre serveur avec la même interface.
  • parce qu’elle permet de créer gratuitement des dépôts privés, accessibles à vous seulement, alors que Github ne le propose que contre argent [1].

Création d’un compte

Rendons-nous donc sur la page d’accueil du service Git de Framasoft, choisissons « Sign In » [2]. Remplissez les informations pour créer le compte, dans la rubrique « New user ? Create an account ». Vous recevrez un mail contenant un lien pour confirmer la création de votre compte. Cliquez sur le lien.

Vous êtes automatiquement authentifiés après la validation du compte. Cependant il vous faudra sans doute vous reconnecter les prochaines fois, via « Existing user ? Sign in », en choisissant non pas la connexion « LDAP » mais « Standard ».

Création d’une paire de clef SSH et mise en ligne de la clef publique

Pour que votre ordinateur puisse envoyer et récupérer l’historique sur le serveur de Framasoft, il faut qu’il communique avec lui en lui prouvant qu’il est bien votre ordinateur, et pas celui d’un tiers.

Plusieurs méthodes sont possibles. L’une est de frapper un mot de passe à chaque nouvelle communication, l’autre d’utiliser un système de clefs SSH.

Pour faire court, vous disposerez d’une clef privée, à garder secrète, et d’une clef publique, à fournir au serveur de Framasoft. Nous allons donc générer ces clefs et envoyer la clef secrète sur le serveur. La génération de ces clefs se fait via le Terminal (sous Mac et Linux) ou le Git Shell (sous Windows).

Tout d’abord vérifier qu’il n’y a pas de clefs déjà générées via :

cat ~/.ssh/id_rsa.pub

Si vous n’obtenez rien, alors c’est qu’il n’y a pas de clefs. Il vous faut donc les générer, via :

ssh-keygen -t rsa -C "email@fournisseur"

En remplaçant email@fournisseur par votre adresse courriel.

Après le retour ligne, une nouvelle ligne apparaît, commençant par « Enter file in which to save the key ». Faite alors un simple retour ligne, pour prendre la valeur par défaut.

Ensuite il est proposé « Enter passphrase ». Choisissez une phrase servant à crypter vos clefs. Donc comprenant des espaces. Ne prenez pas une phrase existante [3]. Votre ordinateur stockera normalement cette phrase de passe dans votre trousseau d’accès. Après votre retour ligne, on vous demande de reconfirmer votre phrase de passe. Faites-le donc.

Ouf, les clefs sont générées !

Il vous rester à fournir la clef publique à Framasoft, on ouvrant le fichier ~/.ssh/id_rsa.pub et en copiant le contenu dans le presse papier. Attention, il vous faut bien copier le fichier finissant par .pub, et pas un autre !

Puis sur votre compte Framasoft, vous rendre sur « Profile Settings », puis l’onglet « SSH Keys », et utiliser le formulaire proposé après « Add SSH Keys ».

Création de votre dépôt distant et mis en relation avec le dépôt local

Il vous faut maintenant créer votre dépôt distant, sur votre compte Framasoft. Sur la page de Framasoft, utilisez le « + » en haut à droite pour créer un « New Projects ».

Dans « Projet Path » mettre le nom de votre dépôt. Par exemple « these ». N’oubliez pas non plus de choisir la visibilité : entre Private (privée) / Internal (visible après authentification chez Framasoft) / Public (accessible à tout.es)

Après validation du formulaire, votre dépôt distant est vide. Il vous faut donc lier votre dépôt local au dépôt distant pour y envoyer les informations. Pour cela, suivre les instructions proposées par Framasoft sous « Command line instruction : existing folder or Git repository ».

Donc :

  • se rendre en ligne de commande à l’emplacement de votre dépôt local.
  • y copier-coller la ligne proposée par Framasoft commençant par « git remote add origin ». Ceci permet de lier le dépôt distant au dépôt local en appelant le dépôt distant « origin ». Par exemple dans le cas de ma thèse, j’ai mis :
    git remote add origin git@git.framasoft.org:maieul/these.git

Ce qui signifie que je relie le dépôt distant situé à l’adresse git@git.framasoft.org:maieul/these.git à mon dépôt local, en donnant comme alias à ce dépôt distant origin.

Envoyer l’historique sur le serveur distant

Au premier envoi de l’historique sur le serveur distant, il vous faut procéder ainsi [4] :

git push -u origin master

Il se peut que votre ordinateur vous demande à ce moment de frapper la « phrase de passe » de votre clef SSH. Il ne devrait le faire qu’une seule fois, l’enregistrant dans son gestionnaire de mot de passe pour les fois suivantes.

Les envois les fois suivantes peuvent se faire avec juste

git push -u origin master

Récupérer l’historique du serveur distant

Supposons maintenant que vous avez un deuxième ordinateur. Vous souhaitez récupérer le dépôt git distant.

Évidemment pour ce faire il vous faut connaître l’adresse du dépôt distant. Rien de bien sorcier : lorsque vous vous connectez avec votre compte sur l’interface web de Framasoft, celui-ci vous liste « Your projects », c’est à dire vos dépôts [5]. Choisissez le dépôt qui vous intéresse.

Tout en haut de la page de chaque dépôt est indiqué de manière très claire son adresse.

Récupérer l’adresse d’un dépôt distant chez Framasoft

Une fois que vous avez copié l’adresse, Il vous suffit simplement de frapper dans votre terminal :

git clone adressedudepotdistant

Ceci va récupérer l’ensemble de l’historique du dépôt distant et le copier en local en un nouveau dépôt. Ce dépôt sera automatiquement relié au dépôt distant [6]. Vous pourrez donc y envoyer vos modifications de l’historique avec git push.

Il ne vous reste donc plus qu’à récupérer l’historique du dépôt distant dans votre dépôt local avant chaque session de travail, via :

git pull

Partager les tags

Dans mon précédent article, j’expliquais comment ajouter des tags pour marquer les grandes étapes du travail. Il faut savoir que les tags ne sont pas envoyés au serveur via git push. Il vous faut envoyer manuellement les tags via git push --tags. De même pour les récupérer, il faut utiliser git pull --tags.

P.-S.

Un autre article sur le sujet par Xavier Lüthi.

Notes

[1Ce qui est normal, puisqu’il s’agit d’une entreprise à but lucratif.

[2«  S’identifier  ».

[3Vous pouvez, et même devez, prendre quelque chose n’ayant aucun sens comme «  Le rat du chat est devenu fou en mangeant des champignons atomiques.  ».

[4Ce qui signifie «  envoyer vers le dépôt git la branche master  », en disant que la branch «  master  » local va suivre la branche «  master  » du dépôt «  origin  ». Une branche correspond à une succession de commit. Il est possible de d’avoir plusieurs branches, mais ce n’est pas la question.

[5À l’heure où j’écris ces lignes, Framasoft propose 42 dépôts par compte. Si vous dépassez cela, il est conseillé de monter son propre serveur d’hébergement Git.

[6Autrement dit le git remote add origin xxx ne sera pas nécessaire.

Qui êtes-vous ?

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

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Acheter XeLaTeX appliqué aux sciences humaines

À propos

Titulaire d’un doctorat en théologie et d’un doctorat en histoire, sous la direction conjointe de Frédéric Amsler et d’Élisabeth_Malamut, je commence à partir du 1er août 2017 un travail d’édition critique des Actes de Barnabé.

Dans le cadre de la rédaction de mon mémoire de master puis de ma thèse de doctorat, j’ai été emmené à utiliser LaTeX, et j’ai donc décider de partager mes techniques. En effet, au cours de mes premiers apprentissages, j’ai découvert que les ressources indiquant les outils pour l’utilisation de LaTeX en sciences humaines étaient rares. Ceci m’a conduit à maintenir ou créer plusieurs packages LaTeX et à donner plusieurs formations.

J’ai reçu en 2018 le prix DANTE e.V pour mon travail autour de LaTeX, en particulier autour de reledmac et reledpar.

Par ailleurs, je suis membre actif de la communauté SPIP, au sein de laquelle j’administre le site Spip-Contrib. Je propose sur ce site quelques notes sur SPIP, en général à destination de webmestre.

Il m’arrive également de faire un petit peu de Python, de temps en temps.

Enfin, je tiens un blog de réflexions politiques et religieuses.

Maïeul