“If you’re not on Github, you’re essentially unable to participate in the rich open-source community that has arisen around front-end development technologies.”

Quand je dis que ma manière de travailler a changé je ne parle pas seulement du résultat final de mon travail mais du processus en lui-même, le workflow. En quelques mots c’est tout ce qui, de l’idée originelle, conduit au résultat final — les étapes suivies, les logiciels et langages utilisés, les pratiques mises en œuvre… bref vous saisissez l’idée. Chacun a sa méthode, chacun a rodé ses étapes, et il est toujours utile de lire et d’étudier la manière dont les autres travaillent.
Beaucoup de choses ont changées depuis que je me suis mis au webdesign, j’ai beaucoup fait évoluer ma méthode personnelle, mais s’il y a une chose que je tiens à mettre en avant en particulier aujourd’hui c’est l’importance du versioning et de sites comme Github.

Le version control en gros c’est l’acte de scinder son travail en versions (et oui). Le terme est assez large, il peut aller du simple fait de créer des versions de son projet (v1, v2) au fait de marquer chaque changement au code comme un point d’encrage en tant que tel, via des technologies comme svn ou git. Je ne vais pas (trop) m’étendre sur ces deux technologies parce qu’il y aurait trop à dire, mais comme le site de Git a il y a peu fait peau neuve je me permets de vous glisser un lien.
Cette article est plus sur le principe du versioning que sur les fondamentaux techniques. Si vraiment vous ne voyez pas de quoi je parle, et ne voyez pas de raisons de lire cette article, faites-le quand même. Le versioning s’applique tant à la programmation qu’au travail graphique – garder un historique de ses images et de son travail en général est un atout énorme, et même si je parlerai principalement de mon cas et de code ici, il y a de grandes chances que cela s’applique à vous aussi.

Dans la poignée de webdesigners que je suis de près, j’étais à une époque tombé sur un article de Rebecca Murphey qui disait « If you’re not on Github, you’re essentially unable to participate in the rich open-source community that has arisen around front-end development technologies. » (Si vous n’êtes pas sur Github, vous êtes fondamentalement incapable de participer à cette riche communauté open-source qui s’est formée autour des technologies du développement front-end [1]). C’est une phrase qui m’a beaucoup marqué, surtout parce qu’à l’époque je ne la comprenais absolument pas.

[1] Rebecca fait ici référence à des technologies comme le HTML5, le CSS3, Javascript, Ruby, PHP, et j’en passe. Le front-end se définit comme tout ce qui se trouve entre l’utilisateur et le back-end (le code moteur), l’interface en quelque sorte.

Historique

Pendant longtemps j’ai laissé ça de côté - parce que je ne voyais pas trop à quoi il était fait allusion, et parce qu’avouons-le, pour qui n’y a jamais touché Git et SVN sont des mondes qui donnent mal à la tête. Faits de branches, de commits, de pull request, de merge et de revisions, et j’en passe. Chaque technologie y va de son petit terme à elle, parfois même pour parler de choses identiques, et quand arrive l’heure de se lancer on peut mettre un long moment avant de saisir réellement ce dont il s’agit.

Dans mon cas j’ai décidé de m’y frotter quand ma petite ébauche de framework a commencé à faire ses preuves, et qu’il devînt de plus en plus complexe de gérer différentes itérations du moteur sur plusieurs projets. De répercuter les bugfixes et améliorations, de savoir où chaque projet en était et ce qui avait changé depuis la dernière fois. Du coup à l’époque je me suis lancé dans SVN, un peu arbitrairement – j’ai placé mon moteur sur un hébergement SVN en ligne (à savoir Beanstalk) pour me faciliter la tâche. Et après quelques coups d’essais j’arrivais à gérer plusieurs versions du moteur sur plusieurs projets — déployer des modifications sur chacun sans me prendre la tête, gérer facilement conflits et historiques, etc.

J’ai toujours considéré que quand on apprend une technologie nouvelle il n’y a de meilleur maître que la pratique. Sans se lancer complètement à l’aveugle non plus, le fait de tenter de mettre en œuvre ses connaissances dans un petit projet, parfois même au fur et à mesure de l’apprentissage, aide beaucoup à comprendre l’ensemble. Ça m’avait aidé à l’époque du HTML, puis du PHP, et ainsi de suite jusqu’à aujourd’hui.
Pour moi, Cerberus - le nom de mon framework - était ma manière de tâter le terrain de manière concrète. Séparer mes modifications en versions et ainsi savoir où en était tel ou tel projet. J’avoue bien sûr que, travaillant seul, il m’est bien plus simple d’expérimenter avec les technologies du web que pour beaucoup de gens.

À mesure que je me familiarisais et rattrapais mon retard avec la scène du webdesign, que j’employais et suivais de nouveaux projets et technologies, j’ai appris à connaître GitHub. Pour ceux qui ne connaissent pas, c’est un site basé sur le principe des repositories : des sortes de “répertoires” symbolisant des projets. Tout s’articule autour des interactions possibles entre eux : les gérer, les héberger, discuter autour d’eux; laisser les utilisateurs disséquer, réparer voire améliorer votre code.
C’est la base de l’open-source : votre code est à la vue de tous, les utilisateurs peuvent venir commenter ou interagir sur chaque ligne. C’est un concept qui peut paraître terrifiant à première vue mais qui révèle bien vite plus de points positifs que négatifs.

Le version control pour tout, partout, tout le temps

Vous l’aurez compris, le principe est de créer une sorte de ligne de temps de votre code. Où chaque modification est distincte des autres, ce qui ouvre tout un monde de possibilités, la plus utile étant sans conteste celle de ramener à tout moment votre code à un instant T. Qui n’a jamais fait une grosse modification sur son code pour ensuite se rendre compte même après tests qu’elle cassait quelque chose d’inattendu ?

De là une fois qu’on y a goûté il est difficile de faire marche arrière, et bien vite je me suis retrouvé à héberger, non plus simplement le code moteur de mes sites sur Github, mais mes projets eux-mêmes.
Ça me donne entre autres une facilité de transport. En ce sens où l’état des fichiers sur le disque n’importe désormais plus - finies les galères avec Dropbox de conflits de fichiers, d’erreurs de copie, et j’en passe. Les commits (modifications faites au projet) sont enregistrés en ligne et je peux décider de télécharger de n’importe où n’importe quelle version de mon projet, de sa naissance à la fin. C’est un outil miraculeux, surtout lorsque l’on travaille à plusieurs ou sur plusieurs postes : chacun peut améliorer un code dans son coin, tout en ayant toujours la dernière version sur son poste. Et si conflit il y a, les fonctionnalités de merge (fusion) de git et svn sont assez malignes pour gérer tout ça. Imaginons par exemple que deux personnes travaillent sur un même fichier et envoient leurs changements en même temps, pour peu que ces changements soient à des endroits distincts du fichier, tout sera habilement combiné en arrière-plan.

On en devient vite accro, de la technologie elle-même certes mais de la communauté autour aussi. Pour tout vous dire, même cet article a été écrit en Markdown (un langage de formatage) sur Gist, la plateforme d’échange de bouts de texte et de code de Github, qui permet elle aussi de créer une instance du fichier à chaque modification, de discuter autour. Bref de faire tout ce qu’on peut en temps normal.

Être au plus près du travail des autres

L’autre point fort comme je l’ai dit c’est la facilité d’interaction et la proximité des développeurs. Quand je repense à il y a quelques années, je pense que jamais je ne me serais imaginé participer de si près au développement des projets qui me sont chers. Lointain est désormais le monde des boîtes à suggestions où on envoyait des emails désespérés en priant pour être pris en compte. La plupart des gros projets sont désormais sur Github. Même PHP - le langage lui-même - est depuis peu passé au Git.
Désormais quand il manque quelque chose dans un projet que j’aime, je ne reste plus les bras croisés - je fork le projet (fait de créer une version séparée), fais mes modifications, et fais un simple pull request pour que mes modifications soient ajoutées automatiquement au projet si le développeur les trouve à son goût. Tout ça parfois en quelques heures – jamais les choses n’avaient été aussi vite.

A contrario quand désormais je tombe sur des projets intéressants qui n’utilisent aucun système public de version control, je ressens toujours une certaine impuissance. Trouvé un bug dans le code ? Envoyez un email et attendez. Envie de suggérer une amélioration ? Passez par les (parfois inexistants) forums et croisez les doigts pour que quelqu’un les lise.
De manière moindre ça me fait aussi un peu ça quand je tombe sur des ancêtres (Sourceforce) ou concurrents (Google Code, qui utilise SVN) de Github.

Oser faire le premier pas

Si vous n’avez jamais touché ni à Github ni à Google Code, essayez. Tout le monde a au moins un projet qui gagnerait à utiliser ces technologies. Et rappelez vous que dans version control il y a control.
De nos jours les pages de démarrage de Github se sont faites moins effrayantes, vous serez guidé pas par pas et tout devrait bien se passer.
Si git et svn restent des technologies qui favorisent la ligne de commande, sachez par ailleurs que de nombreuses interfaces existent, de Mac à Linux. Une bonne poignée est répertoriée sur la page GUI du site git, à l’exception de Github for Windows qui vient d’être lancé.

Si vous êtes un débutant, Github for Mac et Github for Windows (dans un très léché style Metro) sauront se prouver intuitives et vous accompagner dans vos premiers pas.
Si vous êtes plus expérimenté et avez besoin d’accéder à des fonctions plus poussées, Smartgit sur Windows et SourceTree (gratuit) ou Tower (payant) sur Mac seront là pour vous. Au niveau du svn je n’ai testé que Versions sur Mac mais en ai été très satistait.

Ces logiciels répondent tous à une peur de la ligne de commande qui éloigne beaucoup de gens de ces technologies, et c’est une perte grave car se couper d’une communauté aussi passionnée, rassemblée autour de l’open-source et des possibilités offertes, c’est effectivement se priver d’énormément de choses.

Conclusion

Quelques mois plus tard je comprends enfin la phrase de Rebecca et s’il n’y a qu’une chose que je puisse dire c’est que je ne pourrais être plus d’accord.
Les simples technologies citées dans l’article précédent : LESS, SASS, Compass, CoffeeScript, ou d’autres comme jQuery, Ruby on Rails — toutes sont sur Github, ouvertes à discussion, à amélioration.
J’ai récemment vu le développeur d’un plugin pour Compass me laisser les clés du projet car je le développais plus activement que lui.

Le web et les technologies qui l’entourent n’ont jamais avancé aussi vite. Là où avant le HTML et le CSS par exemple étaient des technologies fixes mises à jour toutes les X années, sont désormais devenus des langages mouvants. Des standards en constante évolution par la communauté (ça sera le sujet d’un prochain article).
Si vous voulez commencer à garder le rythme, mon meilleur conseil est de suivre ce qui vous passionne au plus près, à la source. Mon meilleur conseil, c’est de commencer par là.

Note

Mon prochain article se portera sur le Responsive Design. De ses premières ébauches à la (re)découverte des Media Queries, jusqu’à son actuelle forme où les designs adaptatifs ont dans la plupart des cas supplantés les versions mobiles et consorts.

Je discute aussi beaucoup avec des développeurs étrangers et dans l’optique de mieux m’ouvrir à tous j’ouvrirai bientôt un blog compagnon à celui-ci où des versions anglaises de mes articles sur le webdesign seront postées. Ne vous étonnez-donc pas si je lie alors chaque article vers un blog externe, celui-ci reste mon blog principal.