NOTA : cet outil a été développé par un développeur pour des développeurs. Toutefois, il faut bien prendre en compte que nous pouvons versionner n'importe quel type de fichier. Le seul bémol auquel nous pouvons être confronté, dans le cas où les fichiers versionnés ne sont pas des fichiers texte, c'est que votre outil de versioning ne pourra pas afficher le contenu de vos fichiers. Mais cel reste juste un soucis d'affichage du fichier dans l'interface graphique. Sinon, en toute autre point, votre outil s'exécutera et versionnera vos fichiers (mêmes binaires !) de la même façon.

 

Pour comprendre cet article, nous devons remettre dans son contexte le moment auquel nous faisons allusion. Nous avons donc, comme nous l'avons déjà vu, notre dépôt créé, et nous commençons à intégrer, les différentes modifications que nous avons récemment apportés. Comme je le disais dans mon précédent article, un commit doit généralement être relié à une fonctionnalité nouvelle. Cette manière de faire vous permet, dans le cas où vous devriez revenir en arrière, retomber sur un état stable de votre projet. C'est la notion de branche que j'ai expliqué la dernière fois, je ne reviens pas dessus.

Nous avons donc dans notre projet, créé notre dépôt, et au moment de cette création, votre outil de versionning a déjà créé automatiquement un premier commit. C'est votre point de départ. Ce point de départ, prends donc en compte l'état de vos fichiers nouvellement créés. (Bien entendu, il faut déjà une base de N fichiérs présent dans votre projet).

À la suite de votre comit, en tant que développeur, vous attaquez l'écriture ou la modification d'une fonctionnalité dans votre projet. Vous prenez donc votre rôle de codeur afin de faire au mieux ce que vous savez faire de mieux : développer. Ici de nouveaux fichiers peuvent avoir été créés et des fichiers existant modifiés. Certains fichiers peuvent même avoir été suppriimés;

Bien entendu, dans ce cadre-là, j'intègre dans le développement, l'ensemble des modifications que vous apportez. Si vous êtes web designer par exemple la modification vos fichiers CSS peut évidemment rentrer dans le terme développement. Ici, j'ai pris exemple d'un développeur, mais il faudrait prendre un exemple beaucoup plus généraliste : n'importe quel utilisateur avancé modifiant un ou plusieurs fichier's) du projet.

Le temps de lire ce dernier paragraphe, il y a nouvelle fonctionnalité est prête dans votre projet. Vous devez donc à ce moment-là effectuer votre comit. Pour faire une allusion à une de mes pratiques que j'aime aussi, nous pourrions assimiler cette action à la prise d'une photographie de l'état de vos fichiers à un moment donné de votre projet.

Dans cet exemple, je pars du principe que GIT GUI a été ouvert AVANT de faire vos modifications. Cela a son importance car, tout comme sur un navigateur, si vous travaillez sur une page web, dans GIT GUI qui a été resté ouvert, vous devez "forcer" la rééactualisation de l'affichage (comme un F5 sur un navigateur) de l'état des fichiers.  Pour faire cette action, vous avez aussi le bouton Rescan 

Vos fichiers apparaissent dans le cadre en haut à gauche. Ici vous voyez que j'ai modifié le fichier README.md

 

Il vous suffit de cliquer sur l'icone du fichier  pour ajouter à votre commit les fichiers que vous souhaitez prendre en compte. Ils seron déplacés automatiquement dans la fenêtre staged changed :

Vous avez alors préparé votre sélection de fichiers à commiter. Ici, dans la copie d'écran ci-dessus je n'en ai mis qu'un. Mais il est fort interessant de metre l'ensemble des fichiers modifiés de votre nouvelle fonctionnalité. Vous pouvez aussi mettre tous les fichiers du projet, cela dépend de comment vous aimeriez "revenir en arriere" dans le cas où vous souhiateriez ("reevnir en arrier" ou créer une nouvelle branche)

Vos fichiers sont prêts ? Alors désormais notez me message du commit. Ce message est obligatoire (nous verrons où ultérieurement) mais il permet de spécifier ce que vous avez fait dans les modifications de ce commit. C'est justement ici que nous comprenons que GIT n'est pas un outil de sauvegarde mais bien un outil de versionning ! (et oui, je me suis posé la question au début de ma formation GIT)

 

Dans ce paragraphe, je m'attarde au contenu d'un comit uniquement effectué avec le logiciel git. En effet, d'autres outils comme subversion ne fonctionnent pas forcément de cette manière. Je m'attarde sur l'outil de Linus Torvald car c'est aussi le plus utilisé dans nos projets libres.

Ce comit, cette photographie, contient plusieurs informations. Avec l'outil GIT GUI, lorsque vous vous rendez dans le menu dépôt -> visualisation de la branche maître, vous retrouverez l'ensemble de vos comits.

La fenêtre suivante apparait : 

Vous vous rendez compte dans cette copie d'écran, que nous retrouvons en haut l'historisation de vos modifications, avec l'auteur et la date, mais surtout, dans la partie basse, des informations fortes intéressantes sur lesquelles je souhaite revenir.

Dans le 4e cadre en dessous des flèches, vous pouvez vous rendre compte que plusieurs lignes apparaissent. Vous avez l'auteur du comit, l'outil effectuant le comit, et la branche bien évidemment, le parent de la branche courante, etc....

Mais vous avez surtout, juste en dessous du premier cadre en haut à gauche de cette fenêtre, un champ où vous voyez précédé le terme SHA1 id. Vous l'aurez sûrement compris, en visualisant ces deux termes, cette chaîne représente l'identification de votre comit encodéau format SHA1. Je ne reviens pas sur le rôle de SHA1 mais il faut avoir en tête que c'est une fonction de hash coding qui permet de créer une chaîne de caractères unique. Ainsi votre comit est identifié de manière unique.

Dans cette copie d'écran, vous avez aussi sur la partie basse à droite, l'ensemble, la une liste des fichiers qui sont pris en compte dans votre comit.

Enfin, dans le dernier cadre en bas à gauche, vous avez le fichier afficher de manière très particulière. 

 Sur fond vert écrit en verre, vous retrouverez les nouveautés qui ont été ajoutés à ce fichier depuis son dernier comit.

 Sur fond rouge, écrit en rouge, vous retrouvez l'ensemble des lignes ayant été supprimées.

 

Enfin, bien entendu, dans la partie basse de l'écran sur la partie droite, vous retrouverez la liste des fichiers pris en compte dans votre dernier commit. Il va sans dire que, en cliquant sur et un d'entre eux, il s'affichera dans la partie gauche basse de votre écran, sous deux formes au choix : Patch ou Tree.