Git, comment je m’y suis mis. Enfin.

Twitter Facebook Google Plus Linkedin email
closeCet article a été publié il y a 5 ans 2 mois 29 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées, les commandes ne sont peut-être plus valides.

Je dis ‘Enfin’ parce que ça fait déjà un peu plus de deux ans que je développe autre chose qu’un ou deux petits scripts de gestion du quotidien sur le serveur dédié des T-OC. Mais disons que jusqu’à récemment, c’était avec Notepad 2, et… c’est tout. Pour faire du développement sérieux, c’est gérable quand vous êtes seuls, mais disons qu’à un moment donné, faut pouvoir partager correctement sont travail. Petit éclairage par l’exemple, avec une application Web.

Dans l’idée de développer des applications Web (PHP étant mon principal ami), jusqu’ici, je travaillais directement dans un seul dossier, et donc si je pètais quelque chose, plus rien ne marchait, pour la faire court. Et si je n’avais pas pensé à faire une copie avant, point de salut. Bref, arrivé en 2014, c’est un peu laid. Mais ça, c’était avant. J’ai déjà commencé à utiliser des outils un peu plus évolués, comme Sublime Text 2, une hérésie pour un amateur d’open-source, mais qui me permet de réduire drastiquement le nombre d’erreurs que je peux créer (j’ai une ceinture noire de parenthèse non refermée, et un doctorat en point-virgule manquant). Et maintenant, j’ai un puissant outil pour me rendre la vie plus facile : Git.

Git, l’un des plus puissants gestionnaires de versions

Git est donc un gestionnaire de versions décentralisé. Décentralisé parce qu’il est très facile de cloner des dépôts distants, de pousser vers des dépôts distants, bref, de multiplier les dépôts de code pour un logiciel, tout à fait normal quand on travaille sur Internet. De versions, car la puissance de cet outil est notamment de tenir un historique des modifications sur votre code. Il permet aussi de travailler dans plusieurs « branches » d’un même logiciel, vital pour garder une version « potable » pendant que vous jouez à tout casser. C’est très pratique quand vous bossez à plusieurs.

A gauche, Domoticz, à droite, le projet domohouse (très, très w-i-p)

A gauche, Domoticz, à droite, le projet domohouse (très w-i-p, mais l’idée est là)

Un exemple ? Vous avez publié votre branche principale sur un dépôt public (la mode est à Github, j’y reviendrais, vu que j’y ai mis les pieds). Vous avez commencé à travailler sur une branche de développement, parce que vous allez plus que probablement casser quelques fonctions, et que vous voulez garder votre branche principale saine pour le moment. Un utilisateur, qui a cloné la branche principale de votre dépôt public, détecte un bug, et vous en fait part. Vous repassez momentanément sur votre branche principale, vous corrigez le bug, vous envoyez la correction sur le dépôt public, et vous pouvez repartir sur votre branche de développement. Une fois le développement terminé, vous fusionnez votre branche de développement avec la branche principale, et ça conserve la correction du bug ET vos nouvelles fonctionnalités. Eh bien tout ça se fait sans douleur avec Git, c’est l’affaire de quelques lignes de commande, et sans avoir à gérer 50 dossiers par version. Tout se passe dans le même dossier, git remplace les fichiers en fonction de la « version » que vous lui indiquez, de la branche que vous voulez exploiter. Et pour les applications Web, c’est pratique.

(petite note : Git a été créé à l’origine par le papa du noyau Linux, Linus Torvalds. Le projet dépasse les 15 millions de lignes de code, et le noyau est utilisable sur un nombre d’architectures ahurissant).

Cas concret, le projet « domohouse »

Sur une idée de Tom23, j’ai commencé à écrire (nous sommes deux et demi maintenant) une interface simplifiée pour un serveur logiciel de domotique, Domoticz (oh, un projet open-source dis donc). L’interface d’origine fonctionne bien, mais mal adaptée à une tablette, et très moche et peu explicite pour les non-techniciens. Le développement a commencé de manière entièrement chaotique, en se partageant des archives dans la discussion sur le forum spécialisé dans l’auto-hébergement auquel je participe. Très difficile de fusionner les développements parallèles, et donc très facilement plantogène. Il fallait donc disposer d’un outil, et d’un dépôt pour partager le bousin.

git-github_logo

J’ai donc dépoussiéré mon compte Github, créé en Octobre 2012, et qui n’avais jamais servi jusqu’ici (vous comprenez le ‘Enfin’ maintenant ?). J’ai créé mon dépôt « domohouse », pour lequel Github vous place un README et vous propose de choisir la licence. Nous avons décidé d’opter pour la GPLv3. Vient ensuite l’installation de Git sur la machine :

  • Git for Windows pour les Redmondiens (qui sera utilisé au travers de git bash);
  • apt-get install git pour les manchots;
  • pour les végétariens, débrouillez-vous avec votre unix payant.

Je conseille de passer tout de suite deux minutes à configurer deux trois petites choses dans git, comme votre pseudo (ou votre vrai nom, comme vous le sentez), et surtout la coloration de certains évènements. Ca parait inutile vu comme ça, mais croyez moi, quand vous voyez les services que peut vous rendre la coloration syntaxique pour la programmation, un peu de couleur ne fait jamais de mal. Donc :

Je me suis ensuite rendu dans le dossier racine de mon serveur web local (qui ne sert que pour les tests, mais vous pourriez très bien procéder sur votre serveur, ce que j’ai aussi fait d’ailleurs), déplacé mon ancien dossier par sécurité, cloné le dépôt public (ce qui a recréé un dossier ‘domohouse’). Je n’ai plus eu qu’à recopier les fichiers de l’ancien dossier, lui dire de « valider » ce qui était présent, et ensuite, « pousser » les modifications (qui à ce stade se résument à l’ajout des fichiers) sur le serveur. Et vous allez voir, c’est super compliqué comme commandes (pour Linux, sous Windows seules les commandes git blabla sont à taper, le reste peut-être fait avec votre souris, bande de noobs) :

Et voilà !

Exemple du git bash sous Windows

Git bash sous Windows

Mon dossier est maintenant rempli, le dépôt à jour, et l’application est accessible depuis mon navigateur. Je peux dès à présent attaquer les développements, en créant une nouvelle branche, et en m’y plaçant. En ce moment, j’attaque la météo, donc je l’appelle meteo :

J’ai ajouté mon code nécessaire, tout en pouvant le tester en direct (quelques erreurs sont apparues, vite corrigées). Une fois terminé, j’ai indiqué à git de valider ces modifications :

Un petit mot rapide sur git status : cette commande vérifie l’état du dépôt entre le dernier commit et ce que vous êtes en train de faire; ajout de fichier, modification, suppression… Le tout avec quelques couleurs, que nous avons configuré juste après l’installation, et qui rendent justement le visuel d’information plus pratique.

Je ne fusionne pas tout de suite, car je pense avoir encore quelques petits ajouts de code à effectuer à partir des fonctions ajoutées. Mais je peux d’ores et déjà basculer entre la branche master et la branche meteo, et le dossier reflète la branche que je choisis. Je n’ai même pas besoin de faire un « commit » (une version) pour basculer entre les branches, il suffit de faire un « snapshot » qu’on pourra restaurer (un commit étant un point d’étape, il est préférable d’attendre d’avoir terminé le travail en cours pour le faire) :

Bref vous voyez, ça facilite la vie. Une fois que j’ai fini mon expérimentation, je décide d’intégrer mes nouvelles fonctions à ma branche principale. Elle ne sont pas encore directement exploitables, mais tout est cloisonné pour qu’elles ne dérangent pas le reste de l’application. Donc je « commit », puis je fusionne. Enfin, je supprime la branche devenue inutile :

Vers l’infini, et au delà

J’ai à peine effleuré la surface de ce que permet Git. Quand on voit que plus d’un millier de développeurs tout autour du globe l’utilisent autour d’un projet aussi énorme que le noyau Linux (les stats pour le dernier noyau stable en date, le 3.13), on imagine bien la puissance du bousin. C’est un outil populaire, donc les ressources sont nombreuses. Github, malgré tous les défauts qu’un service centralisé peut avoir, est aussi très, très bien foutu, et permet justement un foisonnement de code entre développeurs, une présentation agréable des statistiques de vos dépôts. De nombreux projets populaires y ont trouvé refuge, tel node.js, Bootstrap, jQuery (qu’on utilise pour l’interface de Domohouse), le compte de nicolargo qui regorge de scripts tous plus utiles les uns que les autres (debian post-install, nginxautoinstall, et surtout, glances, le monitoring temps réel qui déchire sa maman; ses contributions me sont très utiles à plusieurs niveaux).

Et chez moi ? domohouse suit son chemin, et devrait bientôt ressembler à quelque chose de cool. Dans un futur proche, je vous présenterais ‘enfin’ (ça devient rengaine, c’est le dernier, promis) Collect, mon projet de collection de DVD/Bluray (mais pas que), qui lui aussi du coup a fini sur Github. Parce que c’est mieux de pouvoir aussi tester ce qu’on lit, et qu’après deux ans de vie, maintenant qu’il sait marcher, il peut aller jouer dans le jardin. On remarquera au passage que j’ai une imagination folle concernant les noms de mes projets…

Poster un Commentaire

avatar
  S’abonner  
Notifier de