Git est un utilitaire de gestion de versions. Ce tutoriel liste les commandes de base pour l’utilisation de Git (la partie installation est décrite dans ce post).

Pour utiliser un dépôt git installé sur un serveur distant, il faut d’abord installer et configurer un client git sur votre machine. Ensuite, les commandes de bases pour récupérer le dépôt, modifier un ou des fichiers, gérer les conflits et taguer une version sont décrites.

Configurer git

Pour pouvoir récupérer le dépôt git, l’utilisateur tux doit posséder un client git

apt-get install git

pour ubuntu ou bien ce lien pour Mac OS X (voir ce post pour l’installation sur une version ancienne de Mac OS X) et ce lien pour Windows. Une fois installé, les commandes suivantes permettent d’initialiser la configuration (nom de l’utilisateur et adresse email) :

git config --global user.name "Tux Dude"
git config --global user.email tux-email@whatnot.com

Enfin, pour configurer l’éditeur de test par défaut des messages de commit (j’utilise nano : basique mais rapide), utiliser la commande :

git config --global core.editor nano

Récupérer un dépôt

Pour récupérer le dépôt nommé testproject sur le serveur server.domain-name.org, on utilise alors la commande suivante (dans un terminal dans le dossier où l’on souhaite installer le dépôt git) :

git clone gitosis@server.domain-name.org:testproject.git

(Attention ! Il faut avoir les droits d’accès au serveur ; par exemple, par mot de passe ou en chargeant une clé ssh). La commande donne une réponse du type :

Un dossier nommé testproject.r est alors créé dans le répertoire courant (dans l’exemple de l’image, le projet s’appelle stage-nicolas). Pour visualiser ce qui a été récupéré, on entre dans le répertoire et on lance l’utilitaire graphique gitk :

cd testproject

gitk &

gitk donne accès à une fenêtre récapitulant les diverses versions, leurs auteurs et leurs dates, ainsi que, pour chaque version, le fichier log de la version, la liste des fichiers modifiés, la nature de la modification ainsi que, pour les fichiers texte, les résultats de diff par rapport à la version précédente ou suivante :

Chaque version du dépôt est identifié par un code SHA1 de 40 caractères du type 76983e194193f6d62f9df57830f3902bc701c2a2 ; cet identifiant est le SHA hash de l’intégralité des objets contenus dans cette version du dépôt. On peut faire référence à une version pour la récupérer, la fusionner avec une autre, la taguer, etc en utilisant son nom SHA1 (ou bien son tag si celui-ci a été ajouté : voir plus loin). Celui-ci est visible dans la fenêtre gitk sous la partie qui contient la liste des versions à la suite de  « id SHA1 ».

Mise à jour d’un dépôt

Une fois le dépôt récupéré, l’utilisateur peut modifier des fichiers ou récupérer des fichiers qui ont été modifiés par d’autres utilisateurs. Il peut également ajouter des fichiers. Les commandes permettant d’effectuer ces diverses opérations sont les suivantes :

• mettre à jour un dépôt en récupérant tous les fichiers distants (il est conseillé d’effectuer cette opération avant de propager ses propres modifications sur le dépôt) :

  git pull

• mettre à jour le dépôt local en ajoutant un fichier example.txtqui n’est pas encore sur le dépôt :

  git add exemple.txt

  ou bien en mettant à jour un fichier modifié old-example.txtmais existant préalablement sur le dépôt

  git commit old-example.txt

  L’éditeur de texte choisi par défaut (pour moi nano) s’ouvre alors qui liste les fichiers qui vont être mis à jour (ici le fichier TODO a été modifié) et demande un message qui explique la nature des changements ; ce message doit être contenu sur une ligne et s’affichera dans gitk :

  
  Une fois le message de log entré, on quitte l’éditeur sans oublié de sauver. Un message indiquant que tout s’est bien passé doit alors être produit.
  On peut aussi mettre à jour tous les fichiers existants déjà dans le dépôt local et modifiés localement depuis la dernière mise à jour par</li>

• git commit -a

  Attention ! Ces opérations mettent à jour le dépôt local uniquement ; pour propager les modifications effectuées sur le serveur, il faut faire :</li>

• envoyer les modifications locales qui ont été enregistrées (par commit) sur le serveur :

  git push

  Si l’intégralité de l’opération commit/push s’est bien passé, on doit avoir un message du type</li> </ul>

  Gérer les conflits

  Si la version locale du dépôt ainsi que la version distante ont été simultanément modifiées, l’utilisation de git pull produit deux situations distinctes :

  • il n’y a pas de conflit d’édition (les deux dépôt ont été modifiés à des endroits différents). Dans ce cas, git gère la fusion et produit un dépôt fusionnant les deux versions ;

  • il y a un conflit d’édition, dans ce cas, git produit un message d’erreur de ce type

  Dans cet exemple, le fichier projetstat.r a un conflit d’édition. Ce fichier étant un fichier texte, git crée un fichier correspondant au résultat de la commande diffentre les deux versions existantes. À ce moment, le fichier projetstat.r présent localement fait apparaître les différences en utilisant des balises du type <<<<<< et >>>>>>. C’est alors à l’utilisateur de procéder manuellement au choix :

  Dans l’exemple ci-dessus, le texte se situant entre <<<<<<< HEAD et ======= est le texte du fichier local ; le texte se situant entre ======= et >>>>>>> 76983e194193f6d62f9df57830f3902bc701c2a2 est le texte de la dernière version du serveur dont l’identifiant SHA1 est 76983e194193f6d62f9df57830f3902bc701c2a2. On procède alors manuellement au choix, pour obtenir, par exemple, le fichier :

  qui contient la version que l’on souhaite conserver (cette version peut être un mélange des deux versions proposées). Lorsque le choix est finalisé, on termine l’opération avec

  git commit -a
  git push

  ce qui produit une fusion de branche visible dans gitk : .

  Lire les statuts

  La commande

  git status

  permet de vérifier le statut des différents fichiers du dépôt. TODO : à finir (à commiter, untracked… + copie d’écran)

  Taguer

  Vous pouvez créer un tag qui référence une version particulière du dépôt git en spécifiant le nom du tag et le nom SHA1 du commit à taguer en options :

  git tag myprettyversion 76983e194193f6d62f9df57830f3902bc701c2a2

  ce qui permet d’utiliser le nom myprettyversion

  pour faire référence à la version 76983e194193f6d62f9df57830f3902bc701c2a2 (ce qui est tout de même plus pratique !). Le tag est ajouté au serveur (pour utilisation par tous les utilisateurs) par

  git push --tag

  Au niveau de gitk, on obtient l’indication suivante :qui indique que l’avant dernière version porte le nom submitted-RR-abstract (les autres versions ne sont pas taguées).

  TODO : checkout…

  </div>