Maintenant que nous avons réussi à installer Git et créé notre dépôt, il est temps de rentrer dans le vif du sujet et de réaliser le premier commit (sauvegarde).

Si tu es débutant en Git et que tu fouilles un peu à gauche et à droite, tu pourras voir qu’il existe une multitude de logiciels pour faciliter l’utilisation de Git.

Mais pour apprendre Git et savoir ce qui se cache dessous, il est impératif de passer par la console et d’utiliser les lignes de commandes. La raison principale est que sur un serveur tu n’auras pas accès à ton logiciel chéri, il est donc primordial de maitriser certaines bases.

Par la suite, je te présenterai quelques logiciels que j’utilise conjointement avec la console et qui sont vraiment cool.

La commande la plus utilisée dans Git est sans doute git status, elle va te permettre de connaître l’état de ton dépôt et de savoir si de nouveaux fichiers ont été ajoutés ou si d’autres ont été modifiés, comme c’est le cas lors d’une mise à jour par exemple.

Et bien on va justement taper cette commande !

Voici le message de retour de la part de Git.

Analysons un peu ce que Git m’a écrit dans la console. Tout d’abord, il y a « On branch master » qui veut dire que je suis sur la branche master (branche principale), pour le moment on ne va pas y prêter attention, mais ça sera important pour la suite.

Ensuite le « No commits yet » qui veut tout simplement dire qu’il n’y a pas encore de commit sur le dépôt (logique).

Enfin, la dernière ligne où Git nous dit quoi faire, c’est assez drôle. Apparement, il faut créer un fichier et ensuite le traquer (suivre) !

On va justement faire ce que nous dit le monsieur ! Je vais créer un fichier index.html (comme tout bon développeur web qui se respecte).

Je vais refaire un git status pour voir un peu ce qui a changé.

J’ai presque les mêmes informations avec quelques trucs qui se sont rajoutés. Git m’indique qu’il y a des fichiers non suivis (untracked) et que je peux utiliser git add <file>… pour les inclure dans ce qui pourra être « commité ».

Et bien faisons-le !

Pas de message d’erreur… Je vais refaire un git status (encore…) afin de voir l’état de mon dépôt.

Cette fois-ci, Git m’indique qu’il y a des changements (mon nouveau fichier) qui peuvent être commit.

Il ne reste plus qu’a faire le commit grâce à la commande suivante :

Git m’a ouvert un fichier au travers de VIM où je vais pouvoir saisir un message pour mon commit. En règle générale, c’est toujours la phrase « First Commit » qui est utilisée pour le tout premier commit.

Lors de la création du commit, Git retourne plusieurs informations, mais moi je vais refaire un git status pour voir si tout à l’air ok.

Et c’est effectivement le cas, car Git écrit clairement dans la console, rien à commit et arbre de travail propre. Ça veut dire qu’il n’y a aucune différence entre mes fichiers et le dépôt.

Si tu n’es pas très à l’aise avec VIM ou que tu veux aller plus vite, tu peux également utiliser l’option -m qui te permet de saisir un message en même temps que la commande de commit et de faire le truc en une seule étape.

Afin de vraiment bien comprendre ce qu’on a boutiqué, je vais te présenter un petit schéma qui illustre les différentes parties lors de l’utilisation de Git.

Le working directory, c’est tout simplement les fichiers qui sont dans ton dossier, généralement en cours de modification et qui doivent être prochainement « commités ».
L’index, c’est une zone intermédiaire avant de « commiter » où tu peux ajouter tes fichiers (d’ou le terme add) provenant du working directory.
Le repository, c’est l’emplacement des sauvegardes (commit) proprement dit dans le dépôt Git.

Une autre manière un peu simpliste de voir les choses est de considérer l’index comme une petite clé USB sur laquelle tu viendrais à copier les fichiers de ton répertoire pour en faire une sauvegarde. Et de voir le repository comme un gros disque dur sur lequel tu viendrais à faire des sauvegardes nommées et datées (versionning) beaucoup plus importantes de ce qu’il y a sur ta clé USB.