Continuer à travailler avec Git quand le serveur est HS : Différence entre versions

De Ensiwiki
Aller à : navigation, rechercher
(Catégories : Git et GL)
m (correction d'une coquille)
 
(6 révisions intermédiaires par 2 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
Travailler avec [[Git]] pour s'échanger du code, c'est bien pratique. En [[Projet GL]], vos étudiants vous fournissent une archive partagée, et pour tous vos TP et projets, vous pouvez [[Créer une archive partagée avec Git|créer une archive partagée]] vous-mêmes pour utiliser un serveur de l'école comme serveur Git.
+
Travailler avec [[Git]] pour s'échanger du code, c'est bien pratique. En [[Projet GL]], vos enseignants vous fournissent un dépôt partagé, et pour tous vos TP et projets, vous pouvez [[Créer un dépôt partagé avec Git|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.
 
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.
Ligne 5 : Ligne 5 :
 
== Solution 1 : pas de panique, il y a un autre serveur ==
 
== 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 (<code>ensibull.imag.fr</code> ici), et beaucoup peuvent travailler sur leur machine personnelle.
+
Le sénario est tiré d'un fait réel : le serveur habituel 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 (<code>ensibull.imag.fr</code> 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 ===
 
=== 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 une archive partagée avec Git]] :
+
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]] :
  
 
<pre>
 
<pre>
Ligne 26 : Ligne 26 :
 
</pre>
 
</pre>
  
La commande <code>git remote add</code> écrit dans la configuration de Git (<code>.git/config</code>) qu'il existe un dépôt distant (remote repository) à l'URL <code><nowiki>ssh://alice@ensibull.imag.fr/~alice/git/Projet_GL.git</nowiki></code>, et nomme ce dépôt « secours », donc on peut utiliser ce raccourcis à la place de l'URL complete dans les commandes comme <code>git pull</code> et <code>git push</code>.
+
La commande <code>git remote add</code> écrit dans la configuration de Git (<code>.git/config</code>) qu'il existe un dépôt distant (remote repository) à l'URL <code><nowiki>ssh://alice@ensibull.imag.fr/~alice/git/Projet_GL.git</nowiki></code>, et nomme ce dépôt « secours », donc on peut utiliser ce raccourcis à la place de l'URL complète dans les commandes comme <code>git pull</code> et <code>git push</code>.
  
 
=== Utilisation du dépôt de secours par les co-équipiers ===
 
=== Utilisation du dépôt de secours par les co-équipiers ===
Ligne 42 : Ligne 42 :
  
 
<div id="utilisation"></div>
 
<div id="utilisation"></div>
=== Travail avec l'archive partagée ===
+
=== Travail avec le dépôt partagé ===
  
On peut maintenant travailler presque comme avec l'archive partagée initiale. S'il veut récupérer des changements de l'archive partagée de secours :
+
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 :
  
 
<pre>
 
<pre>
Ligne 58 : Ligne 58 :
 
</pre>
 
</pre>
  
et comme il en a l'habitude, cette commande va échouer en lui demandant de faire un pull si son archive n'est pas à jour.
+
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 <code>git pull</code> et <code>git push</code>.
 
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 <code>git pull</code> et <code>git push</code>.
Ligne 65 : Ligne 65 :
 
=== Le serveur est revenu ? ===
 
=== 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 étudiants vont chercheur votre code dans l'archive partagée initiale, donc c'est vers celle-là qu'il faut absoluement envoyer votre code.
+
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
 
En fait, rien de plus simple : chaque étudiant fait un
Ligne 73 : Ligne 73 :
 
</pre>
 
</pre>
  
comme il en a l'habitude, et c'est reparti. Si on veut faire du ménage, on peut supprimer l'archive sur le serveur de secours (<code>rm -fr</code>) et nettoyer son fichier de configuration (<code>git remote rm</code>). On peut aussi être un peu plus pessimiste que ça et garder l'archive de secours en place au cas où.
+
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 (<code>rm -fr</code>) et nettoyer son fichier de configuration (<code>git remote rm</code>). 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 ==
 
== Solution 2 : c'est la panique, il n'y a plus de réseau du tout ==
  
On donne maintenant le sé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.
+
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 de l'archive partagée ===
+
=== 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 <code>/media/usb/</code>, mais les instructions sont adaptables.
 
Alice monte une clé USB sur sa machine. On suppose que la machine tourne sous Linux, et que la clé est montée dans <code>/media/usb/</code>, mais les instructions sont adaptables.

Version actuelle en date du 5 janvier 2015 à 16:04

Travailler avec Git pour s'échanger du code, c'est bien pratique. En Projet GL, vos enseignants 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 habituel 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.