Gestion des fichiers et commit

La fonction principale de Git est de suivre les différentes versions d’un projet. Un projet n’est rien d’autre qu’un ensemble de fichiers. De manière très pragmatique, Git ne s’intéresse qu’aux fichiers et ce sont les développeurs qui vont lui indiquer quels fichiers il doit suivre.

Le commit est l’élément central de Git. C’est la pierre angulaire qui permet de lier tous les éléments et tous les concepts de Git. Un commit représente un ensemble cohérent de modifications.

Par exemple, si un développeur corrige un bug, il va indiquer à Git le fichier dans lequel il a effectué la modification et Git va sauvegarder le fichier corrigé (tout en gardant l’ancienne version).

Avant d’aborder la suite du chapitre, il est utile de savoir comment Git voit un fichier.

Une histoire de hash

Un hash (qui peut également être appelé un condensat ou une signature) est une valeur calculée à partir d’une autre valeur. Dans la grande majorité des cas, cette valeur est représentée sous forme d’une chaîne de caractères hexadécimaux. Le calcul du hash fait appel à un algorithme complexe que ce livre ne détaillera pas.

Voici trois exemples de hash calculés avec l’algorithme SHA-1 :

Valeur	Hash
Git	5819778898df55e3a762f0c5728b457970d72cae
git	46f1a0bd5592a2f9244ca321b129902a06b53e03
Je veux une phrase assez longue, au moins plus que le hash en tous cas	7a5a57cde20a9bbda76b70e9223292ce7f8472f9

Nous remarquons deux choses :

Un changement mineur dans le contenu change totalement le hash. Nous remarquons cela en comparant les hashs de « Git » et de « git ».
Un hash SHA-1 fait toujours la même taille : 40 caractères (ce qui équivaut à 160 bits).

Il est impossible de retrouver le contenu original à partir du hash. Au mieux on peut essayer de le deviner, mais on ne peut avoir aucune certitude étant donné qu’un même hash peut correspondre à différentes chaînes. En effet, si on calcule le hash de 2¹⁶⁰+1 chaînes différentes, on a forcément au moins une chaîne qui partage le hash d’une autre (voir la section Risque de collision).

Les hashs sont souvent utilisés pour vérifier qu’un fichier n’est pas corrompu ou alors pour authentifier un utilisateur sans devoir stocker son mot de passe en clair.

1. Une identification...

Les trois zones d’un fichier

Selon son avancée dans le projet, un fichier va se trouver dans l’un de ces trois endroits : le répertoire de travail, l’index ou le dépôt.

Le schéma suivant montre un projet totalement vierge dans lequel un dépôt Git vient d’être initialisé, c’est-à-dire que nous n’avons enregistré aucun fichier dans le projet. La seule action effectuée sur ce projet est un git init.

Pour arriver à ce résultat, nous pouvons utiliser les commandes :

mkdir zoneFichier 
cd zoneFichier 
git init

Pour visualiser l’état des fichiers, nous allons utiliser la commande suivante :

git status

Cette commande affiche la sortie suivante :

git status 
On branch master 
 
Initial commit 
 
nothing to commit (create/copy files and use "git add" to track)

La commande git status permet d’afficher l’état des fichiers du dépôt. Cette commande va être expliquée dans la suite de ce chapitre.

Dans l’exemple précédent, la commande git status précise qu’aucun fichier n’est à commiter (nothing to commit).

1. Le répertoire de travail

Cette zone correspond au répertoire du système de fichiers sur lequel travaille le développeur. C’est le dossier du projet tel qu’il est stocké sur le disque dur. Les fichiers qui se trouvent dans cette zone peuvent être connus de Git selon qu’ils ont été ajoutés au moins une fois dans Git ou non. Un fichier qui se trouve uniquement dans cette zone est un fichier totalement inconnu pour Git.

Ce genre de fichier est également appelé fichier non suivi (untracked file en anglais).

Pour arriver à ce résultat, nous pouvons utiliser les commandes :

echo "<html>Le fichier est dans le répertoire de travail</html>" 
> fichier.html

La commande git status indique que le fichier est visualisé en tant que fichier non suivi :

git status 
On branch master 
 
Initial commit 
 
Untracked files: 
  (use "git add <file>..." to include in what will...

Manipuler les fichiers

1. Ajouter des fichiers dans l’index

Il existe deux cas où il est utile d’ajouter un fichier à l’index :

Le premier cas est celui où le fichier est nouveau et inconnu de Git. Ajouter ce nouveau fichier dans l’index va permettre de prévenir Git que ce fichier doit être pris en compte. Comme expliqué précédemment, ce fichier passera d’un état non suivi à un état suivi par Git.
Le deuxième cas est celui où le fichier est déjà versionné, mais que le développeur souhaite mettre les modifications effectuées dans ce fichier dans l’index pour les commiter.

Pour ajouter un fichier dans l’index, il faut utiliser la commande git add avec la syntaxe suivante :

git add nom_fichier

Il existe également des manières d’ajouter plusieurs fichiers dans l’index à l’aide d’une seule commande. Par exemple, pour ajouter tous les fichiers dans le dépôt, vous devez utiliser la commande suivante :

git add -A

Les bonnes pratiques recommandent aux débutants de ne pas utiliser cette commande. En effet, en l’utilisant, les débutants peuvent ajouter des fichiers dont ils ne veulent pas dans leur dépôt. Ces fichiers peuvent être des fichiers temporaires créés par le système ou tout autre fichier qui n’a pas sa place dans le dépôt.

Cependant, si vous avez un fichier .gitignore bien configuré et que vous êtes rigoureux dans votre relecture de code avant de commiter, l’utilisation de cette commande n’est pas un mauvais choix.

2. Déplacer ou renommer des fichiers

Git propose une commande qui permet de renommer ou de déplacer un fichier. Voici la syntaxe de cette commande :

git mv ancien_fichier nouveau_fichier

Voici par exemple comment renommer le fichier fichier.html en index.html :

git mv fichier.html index.html

La commande git status affiche la sortie suivante :

On branch master 
Changes to be committed: 
  (use "git reset...

Commiter ou enregistrer des modifications

1. Effectuer un premier commit

Le commit est l’élément central de Git. C’est lui qui enregistre toutes les modifications du projet. Un commit doit représenter un ensemble de modifications cohérentes entre elles.

C’est-à-dire qu’un commit ne doit pas servir à sauvegarder des données. Un système de gestion de versions n’est pas un système de sauvegarde. Beaucoup de développeurs qui débutent voient le système de version comme un système qui leur sert à sauvegarder des modifications.

Un exemple permettra de mieux comprendre la philosophie du commit. Un développeur commence à travailler sur une nouvelle fonctionnalité. S’il part en vacances alors que son développement est en cours, il ne va pas commiter ses modifications juste pour faire une sauvegarde. Éventuellement, il aura séparé la nouvelle fonctionnalité en plusieurs petites nouvelles fonctionnalités pour les commiter séparément.

Un commit est en fait un paquet virtuel de modifications. Prenons un dépôt vierge dans lequel sont ajoutés deux fichiers vides :

index.html
style.css

Le développeur code dans ces fichiers une page très simple pour un client désirant juste avoir ses coordonnées sur un site web (le code d’exemple est volontairement simpliste).

Après avoir ajouté ses fichiers à l’index, le développeur commite les modifications avec :

git commit -m "Page de coordonnées"

Par la suite, le développeur ajoute le numéro de téléphone à la liste de coordonnées et commite ses modifications :

git commit -m "Coordonnées : ajout téléphone"

Abordée plus longuement dans le chapitre suivant, la commande git log permet de lister les commits ajoutés au dépôt :

git log 
commit a2ab800 
Author: Samuel DAUZON <git@dauzon.com> 
Date:   Mon Jul 20 23:25:31 2015 +0200 
 
    Coordonnées : ajout téléphone 
 
commit 1480de2 
Author: Samuel DAUZON <git@dauzon.com> 
Date:   Mon Jul 20 23:16:48 2015 +0200 
 ...

Le garbage collector de Git

Dans sa galaxie d’outils internes, Git intègre un garbage collector, ou ramasse-miettes (le nom anglais étant le plus communément utilisé). Cet outil permet de maintenir le dépôt dans un bon état de « santé ». En effet, au fur et à mesure de la vie du dépôt, beaucoup d’objets Git sont créés régulièrement par des commits, des blobs, etc. Cette accumulation peut entraîner des forts ralentissements sur les dépôts.

Le garbage collector a pour but de nettoyer le dépôt afin d’améliorer ses performances et de gagner de l’espace disque. Il va utiliser différents moyens pour parvenir à ses fins :

Compactage d’objets : le garbage collector fusionne les objets isolés en paquets (fichiers .pack). Ce compactage permet d’économiser de l’espace disque, évite de multiplier les fichiers et ainsi de surcharger l’inode (les nœuds d’index internes aux systèmes de fichiers).
La suppression d’objets : le garbage collector supprime tous les objets qu’il juge utile de supprimer, notamment les commits orphelins, les branches supprimées, etc.

Il n’est pas nécessaire d’appeler le garbage collector pour qu’il s’exécute. En effet, un certain nombre de commandes...

Manipulation des fichiers et commit