Comme sur mon site je développe pas mal pour Joomla, nous allons prendre le développement d'un plugin car un plugin possède peu de fichiers. Le faible nombre de fichiers va nous permettre, je pense, d'appréhender plus facilement l'utilisation de l'outil de versionning.

 Afin de faciliter le développement, je m'appuie sur le développement de mon dernier plugin affichant des définitions, ce plugin ne contenant que trois fichiers.

 

Bien entendu, dans ce cas d'utilisation, nous travaillons sur notre serveur local. Il n'est pas conseillé de travailler sur votre serveur distant pour la simple et bonne raison que les transfèrts sont parfois relativement long. Toutefois, ce n'est pas incompatible mais peu conseillé. Il faut donc dissocier la partie Versionning de la partie Upload de fichiers. Sous windows, mac ou linux, vous pouvez utiliser le systeme de liens symboliques pour avoir dans un dossier l'affichage distant FTP. On peut le faire mais je ne le; conseille pas

Comme je vous le disais dans mon précédent article, j'ai toujours utilisé cet outil de la manière suivante :

 

1. Création de son dépôt local avec ses propres sources (à soit ou récupérés si vous souhaitez apporer des modifs). Dans ce cas, chacun des développeurs d'un projet va travailler sur sa propre branche (voir point 3 pour le vocabulaire) dans laquelle il y aura ses propres fichiers. Si vous bossez seul, c'es plus simple : votre branhe = vos propres historisations de vos modifications.

 

2. Lorsque le développeur estime qui doit faire une mise à jour dans le dépôt GIT, il va le faire dans son propre dépôt. Ainsi, la dernière version de son propre dépôt stockera l'ensemble de ces dernières modifications.

 

3. Ainsi, l'ensemble de ses propres modifications validées par un commit au sein d'un projet s'appelle une branche comme nous l'avons vu dans mon dernier tutorial. Ainsi, sa propre branche va se voir incrémenter de l'ensemble de ses propres modifications qu'il fait sur sa partie du projet.

 

4. Si l'utilisateur de cet outil travaille dans une équipe, ce 4e point peut être visualisé comme une "levée de main", demandant au gestionnaire du projet git, d'intégrer ses propres modifications dans la branche globale du projet. Cette branche porte un nom : master (qui a dit qu'il fallait être maso pour utiliser GIT ?)

 

NB : notez bien qu'une branche n'est pas forcément reliée à un développement multi-utilisateur. Une branche va représenter l'ensemble des modifications effectuées sur les fichiers d'un projet, au fil du temps. En effet, si vous travaillez seul à votre compte, votre branche vous appartiendra forcément. L'intérêt dans ce cas, c'est essentiellement de pouvoir historiser l'ensemble de vos modifications, afin de pouvoir visualiser l'historique de votre code, et éventuellement de pouvoir revenir en arrière à un commit donné.

 

Mais, si vous travaillez seul, cette manière de travailler vous permet donc non seulement d'historiser votre travail, mais de pouvoir revenir à une version donnée de votre développement. C'est la raison pour laquelle, il ne faut pas faire de commit n'importe comment.

 

Un commit doit stocker "une photographie" à un moment donné, lorsque une fonctionnalité est fonctionnelle. Cela vous permet, en cas de souci, de pouvoir revenir en arrière sur un projet où votre dernière fonctionnalités comité est propre et à partir de laquelle vous pouvez reprendre un développement.

 

 Si je reviens sur le contenu de mon dernier paragraphe, le gros intérêt de l'outil va vous permettre de pouvoir, en prenant bien en compte le fait de faire un comit au moment où une fonctionnalité est fonctionnelle, de pouvoir reprendre votre projet à l'endroit du git que vous sohaitez ou éventuellement de commencer à creuser vers de nouvelles pistes.

Si je prends l'exemple suivant, vous développez un petit plugin pour Joomla. À un moment donné de votre développement, vous pensez faire des modifications sans être sûr que ces dernières vont correspondre à 100 % au cahier des charges. Là rentre en combte l'intérêt de l'outil de versionning qui va alors vous permettre, à ce moment temporel donné, de prendre votre projet global et de fabriquer une branche. On parle de branche car il faut voir la visualisation de vos différents commit comme un ensemble de développements partant dans "tous les sens". Bien entendu ces sens correspondent à vos fonctionnalités à vous.

Je prends l'exemple suivant. Vous créez un plugin et dans votre développement, vous faites comme moi, ce qu'il ne faut pas faire, vous ne passez pas par des constantes (utiles pourr les traductions) mais par des chaînes de caractères "en dur" directement dans votre plugin, Ces différentes chaînes de caractères, vous vous en rendez compte à temps et vous souhaitez remplacer vos chaines en dur par des constantes. Ainsi, vous pourrez garder l'ensemble de votre projet avec vous chaîne de caractères en dur, mais vous allez à ce moment donné, créer une branche qui va reprendre l'ensemble du projet, et remplacez vos chaînes par vos constantes. Une fois ce remplacement terminé, vous pouvez concevoir que vous avez deux versions de votre plugin. C'est ce qui correspond à deux branches de votre développement.

 

 La réponse est oui mais pour mieux comprendre, je vais ici dans ce paragraphe, vous expliquer la philosophie de votre outil de versionning. Je reprends bien entendu mon développement d'un plugin. Dans ce cas, vous avez créé dans votre répertoire de votre plugin en local sur votre environnement de développement, un répertoire dont le nom porte le nom du plugin. Ceci ne correspond pas git mais uniquement à la manière de développer dans Joomla.

Partant de cet exemple, vous allez devoir créer sur votre serveur local, un répertoire dans lequel vous allez fabriquer vos propres fichiers de développement comme ceux que je présente dans mes différents articles. C'est ce répertoire local qui va devenir votre dépôt.

Je fais tout de suite une petite parenthèse. Cette manière de développer est la manière que j'ai toujours utilisé et c'est cette même manière tu nous avons toujours utilisée dans nos méthodes de développement en petite équipe (3-4 personnes) . Dans ce cas, vous comprendrez aisément que nous travaillons en local et que les fichiers que nous intégrons dans GIT ne sont pas des fichiers distants sur un FTP par exemple. Cette manière de faire est beaucoup plus facile à gérer, que ce soit pour vos développements ou vos tests. De toute façon il est bien évident que lorsque nous travaillons ainsi, nous avons au minimume deux serveurs :

Dans notre cas, la manière dont laquelle nous avons travaillé avec cet outil, nous avions chacun notre propre dépôt dans la mesure où il projet devait être compilé en Java et seulement une fois la compilation effectuée, le projet était déposé sur le serveur.

Notre gestionnaire de dépôt, suite à ma demande, à savoir comment fabriquer travailler lorsque nous travaillons avec un langage de script comme PHP, (qui ne nécessite pas de compilation) , je souhaite savoir si le dépôt pouvait être utilisé par le serveur FTP.

Mon manager de dépôt m'a répondu surtout pas. Il nous a toujours demandé de travailler et nous a recommandé d'avoir chacun sa branche, les modifications sont apportées au fil du temps à la branche "globale" qui GIT appele MASTER. Et une fois cette branche du développeur prête, c'est le gestionnaire de dépôt qui prenait sa branche et qui l'intégrait au projet.

Effectivement dans ce cas nous avons travaillé avec plusieurs personnes. Si vous êtes développeur unique dans votre coin, ce qui est mon cas, j'utilise mon dépôt sur ma machine locale, et c'est dans ce répertoire que les "incrémentations" des nouveaux fichiers se font

Attention, l'ensemble des fichiers est stockés dans la base de données de GIT (je ne saurais vous dire où), et dans le dépôt MASTER vous avez seulement et toujours la dernière version de votre dernier commit. Ainsi, vous avez toujours dans votre dépôt local le dernier commit à mettre en place sur votre serveur dans le cas d'un développement PHP.

Vous avez compris, une branche représente l'ensemble des modifications faites un moment donné, et une branche peut être réexploitée en tant que projet. C'est ensemble les branches qui constituent l'historisation de votre projet.

Le gros intérêt des logiciels graphiques de cet outil c'est qu'ils vous permettent de visualiser graphiquement l'ensemble de votre hiérarchie de vous commits. Graphiquement, ceci se représente comme un arbre n-aire.

Lorsqu'on a ce type d'arbre sous les yeux, il est très facile de comprendre que nous pouvons reprendre n'importe quelle branche de cet arbre et la réintégrer dans son dépôt de travail.

 

Personnellement, c'est en effectuant cette manipulation par notre gestionnaire de dépôt que j'ai enfin compris le fonctionnement de cet outil. Si vous créez en local votre dépôt dans un répertoire, et que vous ouvrez dans votre explorateur de fichiers de ce dit répertoire, que vous allez au fil de vos "rollback" (rechargement de vos fichiers anciens) que ces fichiers courant sont effacés et remplacés par ceux que vous souhaitez restaurer.

Nous revenons donc dans ce cas à une version antérieure pour une raison qui est propre au développeur. Si vous faites cette manipulation tout en ayant sur votre deuxième écran le répertoire ouvert de votre projet, vous allez voir au moment où vous allez revenir en arrière, disparaître l'ensemble des fichiers qui n'ont pas été intégrés dans le commit que vous réintégrer. Ainsi, nous comprenons facilement que une branche affiche une photographie à un moment donné de l'état d'un développement. Une fois que nous avons compris cette manière de faire, l'ensemble des fonctionnalités de git sont maîtrisés

Je souhaite faire vivre cet article et je suis tout à votre écoute si des passages de cet article ne vous paraissent pas clairs. En effet, ayant utilisé l'outil, l'état de choses me paraissent tellement logiques que j'ai peut-être du mal à les expliquer. N'hésitez pas à m'envoyer un mail sur les passage à mieux expliquer. C'est avec grand plaisir que je ferai les modifications nécessaires