Vous pouvez naviguer parmi les posts en glissant votre doigt.

Comment je suis devenu acteur Github

7 septembre 2016 . category: code .
#github

Introduction

Je connais Github depuis très longtemps car je l’utilise beaucoup en tant que consommateur: je prends du code, je l’utilise dans mes projets. J’ai toujours eu la sensation qu’une relation à sens unique ne pouvait pas durer, comme avec les femmes (si on pique trop de lignes de code à une femme, elle nous en veut à la longue).

Avec le recul, je m’aperçois que, du moins pour ce que je vois de mon utilisation de Github, les bonnes volontés conformes à l’intention de départ s’essoufflent. Comme pour tout phénomène, Github vit, et il a de ça de particulier qu’il mélange les cycles commerciaux, scolaires et technologiques, chacun ayant ses avantages et ses inconvénients.

  • les cycles scolaires vont permettre aux utilisateurs novices de découvrir Github en tant qu’utilisateur, et pour certains, de partager leurs innovations. Parmi ces dernières, certaines seront maintenues par leur créateur ou, pour les plus chanceux, la communauté qui se sera créée autour;
  • les cycles technologiques font que telle ou telle technologie devient obsolète ou a le vent en poupe. Par exemple, si Github avait exité au début des années 2000, pas sûr que les projets Javascript aient fait fureur. Quoique c’est probablement l’expansion du Javascript sur Github qui a fait s’adapter les navigateurs;
  • les cycles commerciaux vont faire en sorte que l’accent sera mis sur telle ou telle technologie. Sauf si vous êtes un lapin de six semaines, vous devez vous douter que si une entreprise mise sur une technologie, elle aura tout intérêt à mettre du plomb dans l’aile des technologies concurrentes et garder un maximum de mainmise sur celle sur laquelle elle aura jeté son dévolu, quitte à obfusquer ce qu’il faut pour qu’en dépit du côté “libre”, un utilisateur non averti doive consentir plus d’efforts que nécessaires pour se l’approprier. Cela fait écho au rappel à l’ordre de Linus Torvald qui s’offusquait des complications de code dans des projets liés à Linux, car celles-ci dévoyaient le principe de base. Généralement, un bon code n’est pas un code compliqué avec des méthodes obscures, mais ça, j’y reviendrai certainement dans un autre article.

Ces trois cycles, que je détaillerai également dans un autre article, font que je constate un grand nombre de projets “morts” (i.e. non maintenus), ou certains projets que je considère comme obsolètes maintenus parce que telle société aura fait le choix de telle technologie et qu’elle désire minimiser ses investissements (un peu comme ce qu’elle aurait pu faire avec un hackaton, lui permettant d’acquérir des lignes de code de qualité pondues par des développeurs boutonneux qu’elle aura gavés en Redbull et en pizzas. ROI maximal!).

Je me lance!

De ce fait, j’ai décidé de rentrer en tant que contributeur dans le monde Github, après quelques hésitations. En effet, pour moi, avant que je participe, je pensais naïvement que les codes publiés sur Github étaient le fruit du travail acharné des meilleurs développeurs du monde, et qu’en toute humilité, je n’avais pas forcément toute ma place. Puis, grâce au travail, j’ai pu découvrir le code collaboratif (j’ai installé une Plateforme d’Intégration Continue, dû gérer une équipe aux profils divers, etc.), et j’ai compris que ce qui faisait la force de Github n’était pas les montagnes qui y étaient poussées, mais les petits cailloux que chacun y déposait. En y regardant de plus près, dans la partie submergée de l’iceberg Github, j’ai remarqué qu’il y avait beaucoup de développeurs moyens, et beaucoup de mauvais dévelppeurs. Ouf, je ne serai pas le pire, donc je peux y aller!

Mais par quoi commencer? J’ai pas mal de codes sur lesquels je bosse seul, et un projet laissé en jachère depuis trop longtemps me titillait: mon site perso. J’avais lu dans un GNU/Linux Magazine un article sur Jekyll. Étant habitué au PHP/MySQL, comme beaucoup, j’ai donc décidé de découvrir cette technologie. J’ai trouvé un canevas Jekyll de très bonne qualité, à savoir {Personal}. Je l’ai donc utilisé et effectué quelques tests. J’ai remarqué que le déploiement de sites générés par Jekyll pouvait être amélioré par rapport à ce que décrit la page officielle. J’ai donc proposé sur Github ma solution (qui fait l’objet du premier billet de blog de mon site). Également, j’ai remarqué que {Personal} pouvait être amélioré en corrigeant certaines lignes ou en ajoutant des fonctionnalités. J’ai donc forké le repo et commencé à proposer des pull requests.

Mes premières pull requests étaient un peu n’importe quoi: j’avais commité des changements sur mon master, ce qui fait que pour des pull requests correspondant à des fonctionnalités différentes, il y avait des lignes de codes qui se répercutaient. Ce n’était pas très industriel comme processus (encore une fois, je découvrais). J’ai pris la sage décision de fermer ces pull requests, et couché sur papier ma politique de contribution à Github, que je vous décris maintenant (ah, enfin!).

Mon utilisation de git

Mes projets

Pour mes projets, c’est assez simple (et cette partie sera très brève), je pousse simplement sur Github dès que je suis content. Pour l’instant personne n’a encore effectué de pull requests sur mes projets, mais j’envisage de regarder ce qu’il y a à prendre et d’accepter tout ce qui:

  • simplifiera le code (en termes d’exécution ou de maintien);
  • ajoutera des fonctionnalités intéressantes;
  • permettra une meilleure intégration du code.

Si jamais une pull request demande de modifier l’esprit de mon code, je me réserverais le droit de refuser des modifications.

Projets des autres

Voilà la partie la plus intéressante du billet: je vais détailler comment j’adapte mes publications Github lors de mes intéractions avec les projets que j’ai forkés.

Quand je vois un projet que j’utilise et dont je suis susceptible de modifier le code, je le fork chez moi. Et là, je fais directement une nouvelle branche: master_source. Cette branche à comme vocation d’être la copie du master du projet forké au fil du temps, peu importe ce que je fais moi sur mon master, tout simplement parce que je veux être capable de pouvoir envoyer des pull requests sur le projet forké.

Mettons que je travaille sur deux fonctionnalités (1 et 2). Je crée donc une branche pour chacune des fonctionnalités (pour des besoins de compréhension, j’utilise git checkout -b "fonctionnalité"), et je soumets deux pull requests au projet forké. En effet, pour que mes pull requests soient mieux analysées par le destinataire, je sépare bien les fonctionnalités, plutôt que de lui balancer un gros paquet avec lequel il devra se débrouiller. J’ai donc sur mon repo personnel 4 branches:

  • la master qui contiendra ma version du code (mon fork);
  • la master_source qui contiendra la version du code originale (la source);
  • B1 qui contient les modifications de master_source en y ajoutant la fonctionnalité 1. Je fais un pull request sur le master du repo source;
  • B2 qui contient les modifications de master_source en y ajoutant la fonctionnalité 2. Je fais un pull request sur le master du repo source;

J’en profite pour faire une petite remarque: j’ai eu l’agréable surprise de découvrir que lorsque je poussais sur une branche faisant l’objet d’un pull request, le pull request est actualisé, ce qui fait qu’il n’y a pas besoin d’effectuer une nouvelle pull request à chaque fois qu’on apporte des modifications, et c’est plutôt agréable. C’est donc possible de jeter les premières bases d’une fonctionnalité et d’améliorer cette dernière le temps qu’elle soit prise en compte par le détenteur du repo original.

Pour chacune des pull requests, trois solutions:

  • la branche est acceptée sans changements majeurs: dans ces cas-là, la branche master du repo source est actualisée, et je vais recopier cette branche dans ma branche master_source. Si jamais ma branche master et master_source étaient les mêmes, je répercute également dans mon master (ce cas se produit uniquement s’il n’y avait jamais eu auparavant de pull request rejetée);
  • la branche n’est pas acceptée: dans la mesure où les changements m’intéressaient moi, je les garde dans ma branche master. C’est sur cette branche-là que je continuerai à travailler personnellement. Dans la mesure du possible, si je vois que j’ajoute une fonctionnalité intéressante qui mériterait d’être intégrée dans le master du repo source, je crée une nouvelle branche à partir de ma branche master_source, et proposerai un pull request;
  • la branche est acceptée en partie, mais certaines choses ont été rejetées alors que pour moi elles sont bien, je regarde quelles remarques peuvent s’appliquer à ma branche et je la merge avec mon master. Je merge le master du repo source avec mon master_source. Les deux branches auront alors des fonctionnalités qui se ressemblent, sans forcément que les lignes de codes correspondent exactement.

Pour continuer l’exemple précédent, imaginons que la pull request B1 ait été acceptée mais pas la B2. J’aurai donc la configuration suivante:

Illustration 01

On voit donc que j’aurai répercuté l’acceptation du pull request de B1 sur mon master_source, et même si B2 n’a pas été accepté, je l’ai gardée sur mon master. Normalement, on devrait assez rapidement arriver à cette configuration, dans la mesure où il est peu probable qu’un propriétaire de repo source accepte toutes mes pull requests.

Maintenant, je décide de bosser sur pas mal de fonctionnalités à partir de mon master, et j’aimerais que deux d’entre elles, B3 et B4, soient intégrées au master du repo source. Je vais partir de master_source pour intégrer B3_source et B4_source, cette opération pouvant ne pas être forcément aisée si les codes divergent trop. Je vais ainsi proposer deux pull requests. Mettons que B3_source soit refusée et B4_source acceptée. Tant pis pour B3_source, je garde B3 dans mon master. Pour B4_source, suivant la manière dont elle a été intégrée au master du repo source, je peux effectuer quelques corrections de code avant d’intégrer B4 dans mon master. Bien entendu, je viens copier le master source enrichi de B4 dans ma branche master_source. J’aurai donc la configuration suivante:

Illustration 02

Voilà donc comment je travaille actuellement sur GitHub. Si jamais vous avez des remarques sur ma manière de procéder, n’hésitez pas à m’en faire part, je ferai évoluer cet article selon la pertinence de certaines!


Me

DJ Caësar 9114 est un DJ, qui code également. Il est trop feignant pour faire deux sites différents, alors il n'en a fait qu'un, qui unit ces deux passions.