Les bases de l’utilisation de Git

, par _Eric_

Introduction

L’objectif de cet article n’est pas de répéter une nième fois ce que l’on peut trouver déjà sur le web mais de donner des liens de formation et quelques notions pour une utilisation basique de Git. L’article Plugin Moteur de Notifications / Notification Engine complète le présent article par des cas d’usage rencontrés quotidiennement pour contribuer à SPIP.

Liens d’apprentissage et de référence

Les liens suivants sont recommandés pour se familiariser avec les principes et les commandes de Git et pour consulter les manuels de référence des commandes :

Notions de base de Git

Une gestion d’instantanés

Tous les systèmes de gestion de version gèrent une « base de données » des fichiers, des modifications de ces fichiers et des versions associées (dossier .svn/ ou .git/). Mais Git a une gestion particulière de ces données qui lui confère un avantage certain.

SVN et d’autres systèmes de gestion de version considèrent qu’une version d’un projet est constituée des fichiers initiaux et de la suite des modifications apportées à ces fichiers.

Git agit tout autrement en considérant qu’une version d’un projet est un instantané de tous les fichiers gérés (snapshot). Bien entendu, les fichiers non modifiés ne sont pas dupliqués d’une version à une autre mais juste identifiés par un lien vers le dernier fichier identique. De fait, Git gère une suite d’instantanés.

Une gestion locale

La base de données de Git (le fameux dossier .git/) contient l’ensemble de l’historique du projet. De fait, la plupart des actions Git vont se dérouler en local contrairement à SVN ou autres. Cela est notable sur les performances et sur la capacité à travailler sans connexion.

De fait, pour la plupart des opérations, Git ne fait qu’ajouter des données à sa base de données ce qui rend le système très robuste : contrairement aux autres systèmes, il est presque impossible de perdre des modifications une fois qu’elles ont été enregistrées d’une façon ou d’une autre dans la base Git locale.

Des zones et des états

La zone de travail (appelée aussi working tree ou working directory) est constituée des fichiers du répertoire de travail dans lequel figure une version donnée du projet géré sous Git : les fichiers physiques du projet dans la version concernée que l’on va éditer. Dans la zone de travail :

  • certains fichiers sont gérés sous Git (tracked). Il peuvent dans ce cas être avoir été modifiés par rapport à la version du dépôt Git.
  • d’autres ne sont pas gérés sous Git (untracked). Cet état peut être temporaire (lorsqu’on crée un nouveau fichier du projet) ou permanent (fichier ignoré).

Le répertoire de travail contient à sa racine le répertoire .git/ qui matérialise la base de données de gestion du projet sous Git. Ce répertoire Git contient :

  • le dépôt Git appelée aussi repository ou repo qui stocke l’historique et le détails des modifications enregistrées (commits) sous la forme d’instantanés (donc le dépôt contient sous une forme optimisée les états de tous les fichiers) ;
  • et une zone d’index qui a pour but de préparer les commits en stockant les différences entre la zone de travail et le dépôt.

Cette organisation amène Git à considérer différents états pour les fichiers, états qui sont calculés par rapport au dernier instantané enregistré dans le dépôt :

  • les fichiers non suivis sous Git ou untracked ;
  • les fichiers modifiés ou modified par rapport au dernier instantané, mais pas encore marqués pour faire partie du prochain instantané ;
  • les fichiers indexés ou staged, modifiés et marqués dans leur version actuelle pour faire partie du prochain instantané du projet ;
  • les fichiers validés ou commited, pour lesquels les données d’instantané sont stockées en sécurité dans la base de données Git locale. En fait, l’état de ces fichiers correspond aussi à inchangé ou unmodified par rapport au dernier instantané.

L’illustration qui suit explique comment un fichier passe d’un état à un autre et suite à quelle action ou commande Git.

Dépot local et dépot distant

Il existe deux types de dépôt Git : local et distant.
Le dépôt local est celui qui est hébergé sur votre machine. Le dépôt distant est installé sur un serveur partagé accessible ou pas via une forge par de multiples utilisateurs.

Si l’on développe sur un dépôt local (on a vu que les actions sont toutes faites dans la base Git locale), de temps à autres, il est aussi nécessaire de synchroniser notre dépôt local avec un dépôt distant. C’est le cas des développeurs du Core de SPIP qui partagent le dépôt distant du Core de SPIP sur la forge Gitea de la communauté.

Il existe donc des commandes spécifiques de Git qui permettent cette synchronisation dans les deux sens.

Commandes Git de base

git help affiche les explications sur les commandes Git ou sur une commande particulière à préciser à la suite du help : git help init.
git config permet de modification la configuration Git système, utilisateur ou du dépôt courant.
git init initialise un nouveau dépôt Git dans un répertoire local qui devient de facto une zone de travail pour Git. Le sous-répertoire .git/ est créé et initialisé.
git clone copie un dépôt distant dans un répertoire local. En fait, le sous-répertoire .git/ est copié du serveur, installé dans le répertoire de travail que Git a créé et, par défaut, le dernier instantané est extrait de la base Git pour peupler la zone de travail.
git status vérifie le statut de votre dépôt local et affiche les modifications entre le dernier instantané et l’état actuel de la zone de travail et de la zone d’index.
git add porte à l’attention de Git un fichier non suivi ou indexe un fichier suivi venant d’être modifié. Dans tous les cas, le fichier passe à l’état indexé (staged) dans la zone d’index.
git rm supprime un fichier de la zone de travail et de la zone d’index ou uniquement de la zone d’index. Cette commande ne supprime jamais un fichier de la zone de travail uniquement.
git commit par défaut, cette commande enregistre dans le dépôt Git un instantané des modifications (« commit ») présentes dans la zone d’index, les modifications non indexées n’étant pas prises en compte. Cette action nécessite d’être commentée avec un message précisant les raisons du commit : git commit -m "Mon message". Si l’option -m est omise, Git lance l’éditeur configuré pour saisir le message.
git log affiche la liste des modifications enregistrées dans le dépôt Git appelée aussi « log de commits ». Cette commande possède de multiples options pour obtenir l’affichage désiré.
git fetch récupère toutes les données d’un dépôt distant qui ne sont pas encore dans la base Git locale. La commande fetch tire les données dans votre dépôt local mais sous sa propre branche — elle ne les fusionne pas automatiquement avec aucun de vos travaux ni ne modifie votre copie de travail
git pull agit par défaut comme fetch mais fusionne automatiquement les modifications récupérées sur le dépôt distant dans la branche locale et met donc à jour la zone de travail.
git push pousse les modifications validées d’une branche locale vers une branche distante