Continuer à travailler avec Git quand le serveur est HS

Travailler avec Git pour s'échanger du code, c'est bien pratique. En Projet GL, vos étudiants vous fournissent un dépôt partagé, et pour tous vos TP et projets, vous pouvez créer un dépôt partagé vous-mêmes pour utiliser un serveur de l'école comme serveur Git.

Mais que se passe-t-il si le serveur est en panne ou inaccessible ? Un intérêt des gestionnaires de versions décentralisés comme Git (mais aussi Mercurial, Bazaar...) est qu'on peut assez facilement continuer à travailler dans de bonnes conditions dans ces cas là. Cet article vous propose deux solutions.

Solution 1 : pas de panique, il y a un autre serveur

Le sénario est tiré d'un fait réel : le serveur de promo tombe en panne un week-end, le service info est injoignable (dans la situation réelle, heureusement le service info a pu intervenir dans les quelques heures, ouf !), mais les étudiants ont un compte sur une autre machine (ensibull.imag.fr ici), et beaucoup peuvent travailler sur leur machine personnelle. En 2013, la machine ensibull n'existe plus, donc cette solution n'est plus applicable. La solution 2 est toujours possible par contre.

Mise en place du dépôt de secours

Alice crée le dépôt de secours. En fait, les premières commandes qu'elle lance sont les mêmes que pour Créer un dépôt partagé avec Git :

alice@ensibull$ mkdir -p ~/git/
alice@ensibull$ cd ~/git
alice@ensibull$ git init --bare Projet_GL.git
alice@ensibull$ autoriser-equipe Projet_GL.git bob charlie dave

Mais au lieu d'importer un nouveau projet, elle va importer l'historique du projet en cours :

alice@laptop$ cd Projet_GL
alice@laptop$ git remote add secours ssh://alice@ensibull.imag.fr/~alice/git/Projet_GL.git
alice@laptop$ git push secours --all

La commande git remote add écrit dans la configuration de Git (.git/config) qu'il existe un dépôt distant (remote repository) à l'URL ssh://alice@ensibull.imag.fr/~alice/git/Projet_GL.git, et nomme ce dépôt « secours », donc on peut utiliser ce raccourcis à la place de l'URL complète dans les commandes comme git pull et git push.

Utilisation du dépôt de secours par les co-équipiers

Les autres étudiants vont maintenant se synchroniser avec ce dépôt. Bob fait :

bob@laptop$ cd Projet_GL
bob@laptop$ git remote add secours ssh://bob@ensibull.imag.fr/~alice/git/Projet_GL.git

(attention, l'URL utilise bien bob dans ssh://bob@ensibull... mais alice dans le chemin vers le dépôt ~alice/git/Projet_GL.git)

Bob est maintenant dans la même situation qu'Alice.

Travail avec le dépôt partagé

On peut maintenant travailler presque comme avec le dépôt partagé initial. S'il veut récupérer des changements du dépôt partagé de secours :

bob@laptop$ git pull secours master

(si vous avez utilisé des branches, vous pouvez spécifier la branche que vous voulez récupérer à la place de « master » dans la ligne de commande)

Si Bob a des changements qu'il veut envoyer, il fait par exemple :

bob@laptop$ git push secours

et comme il en a l'habitude, cette commande va échouer en lui demandant de faire un pull si son dépôt n'est pas à jour.

En résumé, donc, les commandes sont les mêmes que d'habitude, mais on ajoute le nom du dépôt distant (secours) sur la ligne de commande de git pull et git push.

Le serveur est revenu ?

Après un moment à travailler avec ce serveur de secours, le serveur revient à la vie. Si c'est en Projet GL, souvenez-vous que les enseignants vont chercher votre code dans le dépôt partagée initiale, donc c'est vers celle-là qu'il faut absolument envoyer votre code.

En fait, rien de plus simple : chaque étudiant fait un

git push

comme il en a l'habitude, et c'est reparti. Si on veut faire du ménage, on peut supprimer le dépôt sur le serveur de secours (rm -fr) et nettoyer son fichier de configuration (git remote rm). On peut aussi être un peu plus pessimiste que ça et garder le dépôt de secours en place au cas où.

Solution 2 : c'est la panique, il n'y a plus de réseau du tout

On donne maintenant le scénario catastrophe, où les machines n'ont plus du tout de réseau. Pas de panique, si vous avez un moyen de transférer des fichiers, comme une clé USB, vous pouvez encore vous en sortir.

Création du dépôt partagé

Alice monte une clé USB sur sa machine. On suppose que la machine tourne sous Linux, et que la clé est montée dans /media/usb/, mais les instructions sont adaptables.

Alice crée un dépôt sur la clé :

alice@laptop$ mkdir -p ~/git/
alice@laptop$ cd ~/git
alice@laptop$ git init --bare Projet_GL.git

Alice a une clé formatée en FAT, donc pas de faire quoi que ce soit pour les permissions. Elle enregistre maintenant le dépôt de sa clé USB comme un « remote repository » de son répertoire de travail habituel et y envoie l'historique actuel :

alice@laptop$ cd Projet_GL
alice@laptop$ git remote add secours ssh://alice@ensibull.imag.fr/~alice/git/Projet_GL.git
alice@laptop$ git push secours --all

Utilisation par un co-équipier

Bob monte maintenant la clé USB sur son ordinateur. Chez lui, la clé se monte sur /media/cle-usb. Il fait :

bob@laptop$ cd Projet_GL
bob@laptop$ git remote add secours /media/cle-usb

puis se synchronise avec la clé, exactement comme dans le sénario 1. La différence est que pour pouvoir utiliser git pull et git push, il faut avoir la clé USB montée sur son ordinateur.

Le serveur est revenu ?

Le retour à la normale se fait exactement comme pour le sénario 1.

Alternatives

Parmi les solutions alternatives, on peut citer :

• L'utilisation d'un hébergeur extérieur à l'Ensimag. Attention, la plupart des hébergeurs fournissent des dépôts gratuits à condition d'être publics, et la charte des TP de l'école vous interdit de déposer votre code sur un site public.

• L'échange de patch par email. On vous a sans doute appris que s'envoyer du code par email était une mauvaise idée, mais s'envoyer des patchs est tout à fait raisonnable (c'est même comme ça que fonctionne le développement de l'outil Git lui-même !). Les commandes git format-patch et git send-email permettent d'automatiser la création de patch et leur envoi en nombre, et la commande git am permet d'appliquer ces patch pour créer des commits.

• L'échange de « bundle » par email. Un « bundle » est un morceau de dépôt Git, compressé, et prévu pour être appliqué à un autre dépôt. Le résultat est proche de ce qu'un git pull aurait fait, mais on n'a pas besoin d'avoir une connection réseau entre les machines qui communiquent.

• L'échange de code directement d'une machine à l'autre via git pull. La difficulté ici est que bien souvent, les machines sont sur un réseau IP privé (typiquement, les box ADSL des FAI sont en général des modem-routeurs qui donnent une IP privée à chaque machine, mais ne rend pas par défaut la machine visible du reste d'internet). Parmi les solutions : avoir toutes les machines derrière le même modem-routeur et utiliser les IP privées, utiliser IPv6, ou rediriger des ports pour rendre le serveur SSH de sa machine visible de l'extérieur.