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.
Sommaire
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
etgit send-email
permettent d'automatiser la création de patch et leur envoi en nombre, et la commandegit 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.