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 deux 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

Dans cet exemple, nous remarquons deux choses :

Un changement mineur dans le contenu change totalement le hash. Nous remarquons cela en comparant les hash de « Git » et « git ».
Un hash 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 par contenu

En interne, Git travaille sur un certain nombre d’objets (contenus dans le dossier .git/objects) : des fichiers, des dossiers, des commits, etc.

Tous les éléments que Git manipule sont...

Les trois zones d’un fichier

Un fichier peut se trouver à trois endroits différents : le répertoire de travail, l’index et le dépôt. Le fichier va se trouver dans les différentes zones selon son avancée dans le projet.

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, vous pouvez 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 à l’aide des exemples qui vont suivre dans la suite de ce chapitre.

Dans l’exemple précédent, la commande git status nous 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...

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 de ne pas utiliser cette commande. En effet, en utilisant cette commande, il est possible d’ajouter des fichiers dont nous ne voulons pas dans notre 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.

2. Déplacer ou renommer des fichiers

Git possède 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 nous affiche la sortie suivante :

On branch master 
Changes to be committed: 
  (use...

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. Le 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.

Plus simplement, un commit est un paquet virtuel de modifications. Par exemple, en utilisant un dépôt vierge dans lequel seraient 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"...

Manipulation des fichiers et commit