Démarrer un dépôt Git
Un “dépôt” correspond à la copie et à l’importation de l’ensemble des fichiers d’un projet dans Git. Il existe deux façons de créer un dépôt Git :
- On peut importer un répertoire déjà existant dans Git ;
- On peut cloner un dépôt Git déjà existant.
Nous allons voir comment faire cela dans la suite de ce cours. Avant cela, je pense qu’il est bon de comprendre comment Git conçoit la gestion des informations ainsi que le fonctionnement général de Git.
La gestion des informations selon Git
La façon dont Git considère les données est assez différente de la plupart des autres systèmes de gestion de version.
Git pense les données à la manière d’un flux d’instantanés ou “snapshots”. Grosso modo, à chaque fois qu’on va valider ou enregistrer l’état d’un projet dans Git, il va prendre un instantané du contenu de l’espace de travail à ce moment et va enregistrer une référence à cet instantané pour qu’on puisse y accéder par la suite.
Chaque instantané est stocké dans une base de donnée locale, c’est-à-dire une base de donnée située sur notre propre machine.
Le fait que l’on dispose de l’historique complet d’un projet localement fait que la grande majorité des opérations de Git peuvent être réalisées localement, c’est-à-dire sans avoir à être connecté à un serveur central distant. Cela rend les opérations beaucoup plus rapides et le travail de manière générale beaucoup plus agréable.
Les états des fichiers
Comment Git fait il pour suivre les modifications sur les fichiers d’un projet ? Pour comprendre cela, il faut savoir qu’un fichier peut avoir deux grands états dans Git : il peut être sous suivi de version ou non suivi.
Un fichier possède l’état “suivi” si il appartenait au dernier instantané capturé par Git, c’est-à-dire si il est enregistré en base. Tout fichier qui n’appartenait pas au dernier instantané et qui n’a pas été indexé est “non suivi”.
Lorsqu’on démarre un dépôt Git en important un répertoire déjà existant depuis notre machine, les fichiers sont au départ tous non suivis. On va donc déjà devoir demander à Git de les indexer et de les valider (les enregistrer en base). Lorsqu’on clone un dépôt Git déjà existant, c’est différent puisqu’on copie tout l’historique du projet et donc les fichiers sont tous déjà suivis par défaut.
Ensuite, chaque fichier suivi peut avoir l’un de ces trois états :
- Modifié (“modified”) ;
- Indexé (“staged”) ;
- Validé (“committed”).
Lors du démarrage d’un dépôt Git à partir d’un dépôt local, on demande à Git de valider l’ensemble des fichiers du projet. Un fichier est “validé” lorsqu’il est stocké dans la base de donnée locale. Lors du clonage d’un dépôt déjà existant, les fichiers sont enregistrés par défaut en base et ils sont donc validés par défaut.
Ensuite, lorsqu’on va travailler sur notre projet, on va certainement ajouter de nouveaux fichiers ou modifier des fichiers existants. Les fichiers modifiés vont être considérés comme “modifiés” par Git tandis que les nouveaux fichiers vont être “non suivis”. Un fichier modifié est considéré comme “modifié” par Git tant qu’il n’a pas été indexé.
On dit qu’on “indexe” un fichier lorsqu’on indique à Git que le fichier modifié ou que le nouveau fichier doit faire partie du prochain instantané dans sa version actuelle.
Enfin, lorsqu’on demande à Git de prendre l’instantané, c’est-à-dire lorsqu’on lui demande d’enregistrer en base l’état du projet actuel (c’est-à-dire l’ensemble des fichiers indexés et non modifiés), les fichiers faisant partie de l’instantané sont à nouveau considérés comme “validés” et le cycle peut recommencer.
Les zones de travail
Les états de fichiers sont liés à des zones de travail dans Git. En fonction de son état, un fichier va pouvoir apparaitre dans telle ou telle zone de travail. Tout projet Git est composé de trois sections : le répertoire de travail (working tree), la zone d’index (staging area) et le répertoire Git (repository).
Le répertoire de travail ou “working tree” correspond à une extraction unique (“checkout”) d’une version du projet. Les fichiers sont extraits de la base de données compressée située dans le répertoire Git et sont placés sur le disque afin qu’on puisse les utiliser ou les modifier.
La zone d’index ou “staging area” correspond à un simple fichier, généralement situé dans le répertoire Git, qui stocke les informations concernant ce qui fera partie du prochain instantané ou du prochain “commit”.
Le répertoire Git est l’endroit où Git stocke les méta-données et la base de données des objets de votre projet. C’est la partie principale ou le coeur de Git.
Le processus de travail va ainsi être le suivant : nous allons travailler sur nos fichiers dans le répertoire de travail. Lorsqu’on modifie ou crée un fichier, on peut ensuite choisir de l’indexer. Tant qu’un fichier n’est pas indexé, il possède l’état modifié ou est non suivi si c’est un nouveau fichier. Dès qu’il est indexé i.e que son nom est ajouté à la zone d’index, il possède l’état indexé. Finalement, on va valider (“commit”) la version indexée de nos fichiers pour les ajouter au répertoire Git.
Pour retenir ces informations, vous pouvez vous aider des schémas ci-dessous (source : git-scm.com).
