Gestion GIT#

Un repository global a été mis en place sur curry. Il est situé dans /repos avec les permissions 777, appartient à root et au groupe users.

Création d’un repository à partir de sources locales#

Un dépôt partagé est un dépôt auquel plusieurs personnes ont accès, et vers lequel elles peuvent faire des push et des pull. On présente ci-dessous la procédure pour la création du dépot lmptools, un ensemble de logiciels pour lammps.

On souhaite que le dépôt se trouve sur la machine curry dans le répertoire qui contient l’ensemble des dépôts git : /repos/.

1 - Initialisation du dépôt (par le resp. du dépôt)

> cd /repos
> git init --shared --bare lmptools.git

2 - Changement des permissions pour permettre aux membres de mon groupe d’écrire dans ce répertoire :

> chmod -R u+rwX,g+rwX,o-rwxX lmptools.git

3 - Remplir le dépot

a - Je vais d’abord cloner le dépôt vide dans mon répertoire de travail, par exemple /userTMP/rousseau/

> cd /userTMP/rousseau > git clone ssh://rousseau@styx/u2/commun/gitroot/lmptools.git lmptools

b - On remplit le répertoire lmptools avec les sources qui existent ou bien on crée de nouvelles sources.

c - On ajoute ces sources dans son repository local

git add * git commit -m « Dépôt initial des outils lmptools »

d - On peut maintenant faire un push sur le dépot partagé (/u2/commun/gitroot/lmptools.git). Il faut utiliser l’option `push`uniquement pour le premier push :

git push –all

Mise en place du hook multimail#

Ce hook permet d’informer une liste d’utilisateurs d’un repository donné lors de push sur curry. Il s’installe et se configure pour chaque repository où cette fonction est désirée. Un clone de git-multimail est installé dans /usr/local/prod pour des installations ultérieures.

On peut ensuite utiliser le script python git_multimail.py en le copiant dans le dossier hooks du repository souhaité.

sudo git clone https://github.com/git-multimail/git-multimail.git

cd git-multimail/
cp ./git_multimail.py /repos/lmptools.git/hooks/post-receive

Il faut ensuite modifier le fichier config pour ajouter le champ multimailhook et la liste des destinataires d’email :

[multimailhook]
    mailingList = bernard.rousseau@cnrs.fr, toto@email.edu
    mailer = sendmail
    from = pusher

git pour les développeurs et utilisateurs de logiciels#

Configuration utilisateur#

Commencer par entrer les options de configuration locales suivantes :

git config –-global user.name "Votre NOM"
git config –-global user.email myemail@u-psud.fr
git config --global color.ui true

On peut également créer un fichier .gitignore à la source du working tree (au même niveau que le répertoire .git). Ce fichier permet d’éviter que certains fichiers soient analysés par git. Mon fichier .gitignore contient par défaut

.gitignore
*.o
*.mod

Clonage d’un repository et mise à jour des sources#

Un nouvel utilisateur peut récupérer le contenu d’un repository en le clonant sur sa machine. Cela lui permet de disposer des sources du logiciel pour compilation sur sa machine et, éventuellement, apporter des modifications. Si l’utilisateur se trouve sur la machine styx, la commande

> cd ~ > git clone /u2/commun/gitroot/lmptools.git lmptools

va cloner le repository lmptools.git dans le répertoire lmptools dans le home de l’utilisateur. Si l’utilisateur souhaite cloner le repository sur une autre machine qui possède un accès ssh sur styx, il peut utiliser la commande

en remplaçant USERNAME par son login sur la machine styx et éventuellement styx par styx.lcp.u-psud.fr.

Lorsque des modifications sont réalisées par un autre développeur, on peut mettre à jour sa version locale en utilisant la commande git pull :

> cd lmptools > git pull

Il faut ensuite compiler les sources pour mettre à jour l’exécutable.

Modification des sources#

Chaque développeur doit travailler dans son working tree puis, après validation, commiter ses changements et, enfin, mettre à jour le repository.

La commande

> git status

permet de lister les fichiers modifiés dans le working tree, c’est à dire la branche locale du repository.

Lorsque vous réalisez des modifications ou créez de nouveaux fichiers, vous pouvez utiliser la commande

> git add toto.f90

pour mettre à jour l’index qui contient un instantané du working tree. Le fichier correspondant est staged, i.e. prêt pour le prochain commit… Il est suivi par git. La commande git add permet à la fois d’ajouter de nouveau fichiers dans le working tree et de prendre en compte les modifications des anciens fichiers.

La commande

> git diff toto.f90

permet de voir la différence entre la version correspondant au dernier commit et la version actuelle.

Lorsque les modifications ont été validées et testées, vous pouvez faire un commit :

> git commit

Cette commande ouvre un éditeur de texte (vi par défaut) pour entrer un message qui permettra de se souvenir des modifications qui ont été réalisées. Attention à la rédaction de ce message. Je propose de rentrer au minimum

  • le nom du fichier modifié avec le chemin complet dans le repository

  • le nom de la sous-routine/fonction/module modifié

  • un commentaire qui explique les raisons de la modifications et ce qui a été modifié.

La commande

> git log

dresse la liste des commit réalisés dans le working tree local.

Il faut ensuite publier ses modifications en mettant à jour le repository distant (celui utilisé par tous les développeurs pour cloner et mettre à jour leur version). Ceci se fait en utilisant la commande

> git push

La commande

> git diff –stat ./

permet d’avoir une vison globale dans changements réalisés sur l’ensemble des fichiers du répertoire courant.

Création d’un tag#

Pour gérer l’ensemble des fichiers qui représentent une version finalisée d’un code, on peut utiliser les tags. J’utilise un tag annoté :

> git tag -a v1.2.3 -m « version 1.2.3 »

Il faut ensuite pousser le tag (sinon il est uniquement local) :

> git push origin v3.9.3

Ainsi, un autre utilisateur qui clonera le logiciel pourra voir les tags disponibles.

La commande git tag sans option donne la liste des tags. La commande

> git show v1.2.3

donne des informations sur un tag particulier.

## Récupération de l’archive d’une version taguée

On peut récupérer une archive d’une version taguée à l’aide de la commande :

> git archive -o nt393.tar –prefix=newton_v393/ v3.9.3

L’option prefix permet de créer le répertoire indiqué lors de l’extraction du tar. Ne pas oublier le /. L’option -o nt393.tar indique le nom de l’archive. v3.9.3 est le nom du tag tel qu’affiché avec la commande git tag.

Pour plus d’infos…#

De nombreuses autres informations sur `git` peuvent être obtenues aux adresses suivantes :

https://git-scm.com/book/en/v2 in english https://git-scm.com/book/fr/v2 en français