Comme certains me demandait, comme cet outil est très utilisé dans le développement, comme nous développons tous un petit peu, que ce soit de simple feuille de Sting ou des composants un peu plus complexes pour Joomla, il n'est pas rare que nous soyons très souvent submergé par nos fichiers et surtout pas la gestion de leur version. Inutile de faire des copies dans tous les sens, nous avons aujourd'hui voir un outil de version ligne créé par l'excellent Linus Torvald, fondateur et maintenancier du noyau Linux.
Concept à comprendre
GIT permet de versionner votre propre code sur votre propre environnement de développement. J'entends pas environnement de développement, la "zone de travail", le "dossier de travail" sur lequel vous travaillez surant l'écriture de vos programmes. GIT étant un outil décentralisé, vous n'avez pas besoin d'entrepôt de travail pour utiliser GIT.
Sachant lire dans vos pensées, je sais que vous vous demandez "mais alors github, ca sert à rien ?" Ben non, d'un point de vue purement developpeur, ca ne sert strictement à rien.
En revanche, d'un point de vue partage de code, Github va vous permettre de "stocker en ligne" vos différents états de code. Il faut voir Github comme un serveur de partage relié à la fonctionnalité de versionning. Mais ca "reste" un espace de stockage pour du partage de code, (avec les fonctionnalité avancées de partage GIT). Nous verrons l'utilité de Github sûrement dans un prochain article.
L'idée étant, pour un développeur tiers, de pouvoir "forker", c'ést à tire, prendre votre branche et retravailler dessus, et éventuellement redonner le travail au développeur du début. Mais ce n'est pas obligé. En effet, un fork très célèbre est libre office, qui est (si je ne me trompe pas de sens) un fork de OpenOffice. C'est souvent le cas lorsqu'un à un moment donné, les developpeurs de produits libres ne sont plus sur la même longueur d'ondes... A l'époque je ne connaissais pas Joomla mais si j'ai bien compris, c'est ce qu'il s'est au passage de mambo à Joomla
Création d'un projet
Dans un premier temps, pour utiliser un outil de versionning comme git, nous devons créer un projet, que l'on nomme aussi un dépôt. Pour créer un projet, il faut dans un premier temps créer un dossier, rentrer dans le dossier, initialiser le dossier au moyen de git, c'est-à-dire demander au logiciel GIT d'aller explorer le contenu de ce répertoire dans un but des garder des snapshots. Une fois la commande git lancée, vous retrouverez le fameux fichier .git dans le répertoire, cela veut dire que le logiciel va commencer à surveiller le contenu du dossier. (et pour ceux qui l'ignorent, un fichier qui commence par un . est un fichier masqué... sous linux/mac). Donc le fichier .git est caché sur un vrai système d'exploitation.
md mondossier
cd modossier
git initgit-statusAfin de bien suivre le développement de mon argumentaire, nous allons travailler avec des fichiers HTML en guise d'exemples.
Iniitialisation du dépot : git-init
Je reviens rapidement sur la commande git-init. Cette commande créé un dépôt git. Cette commande peut aussi éventuellement réinitialiser un dépôt mais contentons nous de la simple création. Une fois cette commande effectuée, le dépôt est pret à travailler.
L'équivalent de cette commande dans git GUI est un clic dans l'hyperlien Creatée new Repository
Etat du dépot
Il est possible de connaitré l"'état" du dépôt.avec la commande git-status . En lançant cette commande, on récupère l'état du dépot :
Avec GIT GUI, cette commande n'a pas à être véritablement lancée car l'état du dépôt est affiché dans l'interface Homme Machine (IHM). En effet, vous pouvez voir dans le coin bas gauche que le fichier README.md est prêt à être versionné.
Demande de snapshot
Je n'aime pas cette terminologie dans le cadre d'outils de versionning mais il est vrai que cela permet de bien comprendre l'état des choses.
Si, à ce moment précis, de je demande à git de versionner l'éat de mes fichiers, il va créé une sorte de "photographie" de l'état des fichiers, une sorte de snapshot, un point de "restauration" du contenu des fichier. Pour ce faire, l'utilisateur doit cliquer sur Commit.
Sur l'interface graphique, il suffit de spécifier les fichiers à ajouter au commit, en les sélectionnant de la zone Unstaged changes. Cependant, pour effectuer cette même opération en mode CLI, il suffit de lancer la commande git add README.md où README.md est le fichier à ajouter au commit
Le message de commit est OBLIGATIOIRE, il permet aux développeurs de comprendre pourquoi ce commit a été fait à cet instant précis.
Apres avoir cliqué sur COMMIT ou lancé la commande CLI git commit, le commit est effectué. Notons toutefois que le commentaire étant obligatoire la commande complète du commit est git commit --message "Mon message"
Désormais pour connaitre l'état du dépôt, il suffit de lancer la commande git status
Correction du dernier commit
Vous voyez dans le copie d'écran ci-dessus la case à cocher Amend Last Commit ? 
Je ne sais plus comment cette case à cochér est traduite en français mais cette case sert tout simplement, si vous la cochez AVANT de cliquer sur le bouton commit, de faire une CORRECTION de votre dernier commit au lieu de faire un nouveau commit.
Historisation des commit
Certes le but de GIT est de pouvoir "revenir en arrière" mais surtout, son but technique est d'historiser les changements des fichiers source d'un projet. Il existe bien entendu la commande git log qui permet de lister l'ensemble des modifications effectuées sur un projet.
Au niveau de GIT GUI, l'équivalent de cette commande est accessible par le menu Repository-> Visualise master history
En sélectionnant cette option, vous allez retrouver l'ensemble de l'historisation du projet. Alors oui je sais, j'interface vaut ce qu'elle vaut avec GIT GUI mais vous allons la détailler zone par zone. Mais avant de rentrer dans le détail, voici l'interface que sur laquelle vous aller tomber :
Rentrons dans le détail graphique en se basant sur la numérotation suivante des zones de la fenêtre :
Les zones n° 1, 2 et 3 sont reliées entre elles. Il faut considéré chacune des zone pour UNE LIGNE SELECTIONNEE.
Zone n°1
Dans cette zone, vous aller rertrouver l'ensemble de "l'arbre" des modification apportées au projet GIT. J'ai numéroté 3 zones 1,2 et 3 mais en fait, il faut avoir une vue d'ensemble de ces 3 zones : chacune des lignes correspond à un commit.
Dans cette zone 1, une ligne va correspondre à un commit avec son commentaire. La première ligne correspond donc généralement à master (je n'ai jamais vu master ailleurs) dans la mesure où master doit être votre "copie/version courante" ou version de travail.
Zone n°2
Dans cette zone, en relation ligne à ligne à la zone n°1, vous retrouverez l'auteur du commit
Zone n°3
Dans cette zone, toujours pour une ligne sélectionnée, vous allez retrouver la date du dernier commit
Zone n°4 et 5
J'ai tendance à considérer cette zone comme un ensemble de données techniques pas forcément utiles. Toutefois, vous retrouverez le hash du commit, un mini moteur de recherche de commits, des conditions de sélections... Cela peut être utile, mais ,je ne m'en suis jamais servi. Toutefois, si vous régigez des dossier de programmation, vous pouvez addoser à votre dossier des références de commit et leurs dates. Cela peut avoir un intérêt rédactionnel.
Zone n°6
Vous retrouverez dans cette zone des information sur le commit comme son auteur, des dates, des références de branches, le noeud parent.... Cela peut servir là aussi dans des dossiers, personnellement ces onlformations ne m'ont jamais été utiles, même en travail en équipe (petite équipe) mais elles ont le mérites d'être présentes.
Toutefois, dans la version basse de cette zone, vous retrouverez
- en vert les lignes ajoutées
- en noir les lignes non touchées
- en rouges les lignes supprimées
depuis la dernière version.
Zone n°7 (non numérotée)
Vous retrouverez sous la forme d'un arbre (en cochant tree) ou non (option patche) l'ensemble des noms de fichiers modifiés
Les boutons
Si nous repartons sur l'interface de départ, nous avons 5 boutons que nous allons détailler, en prenannt le compte la méthodologie de leur utilisation.
Rescan
Ce bouton correspond à votre bouton réfraichir de votre navigateur. En effet, le fonctionnement clasique de windows fait qu'aucun outil ne va analyser en temps réel un contenu (ce que l'on a par exemple sur MacOS). De ce fait, lorsque vous avez modifié un fichier sans pour autant avoir fermé Git GUI, vous etes obligé de cliquer sur ce bouton de manière à voir les corrections du fichier.
En revanche, si vous lancez GIT GUI, cette analyse est automatiquement lancée au lancement de GIT GUI. Or, comme les dévloppeurs gardent GIT GUI toujours ouvert en arrière plan, ce bouton est nécessaire.
Stage changed
Ce bouton permet en un clic d'indexer toutes les modifications apportées en un clic. Si vous avez bien suivi mes tutoriels, vous aurez compriis qu'il ne faut donc jamais utiliser ce bouton, car comme il va tout indexer d'un coup, il se peut qu'il indexe aussi des éléments qui ont été modifiés lors de plusieurs changements fonctionnels. Cela peut en effet poser de gros soucis si vous souhaitez "revenirt en arrière" : vous risquez de perdre certaines fonctionnalités développées.
Sign off
Sign off offre la possibilité d’ajouter une signature à votre commit en rajoutant votre nom et adresse mail issus de votre giot config.
Commit
Ce bouton is THE BUTTON : c'est lui qui vous permet de faire un commùit apres avec renseigné, c'est obligatoire, un message de commit dans le rectangle juste à gauche de la zone des boutons.
Push
Personnellement, le choix politique que nous avions était de ne jamais faire de push, c'est un choix politique. Seul le responsable de nos dépôts faisait le push et donc nous ne l'utilisions pas. Toutefois, et vous l'oufez compris, ce bouton vous permettre de possuer sur votre serveur de vesionning votre version terminée. A priori, il y a deux trois innformations à remplir mais n'ynt jamis pratiqué ainsi, je ne souhaite pas raconter de bétises. Toutefois, effectivement, dans le cadre de partage de code sur des plateformes type github, ce push est necessaire.
