Le projet WebKit adopte pleinement Git et GitHub

Nicolas Furno |

Le blog du projet WebKit annonce une transition importante : le moteur de rendu web d’Apple, utilisé notamment par Safari, adopte pleinement l’outil Git pour le suivi des versions et le service GitHub pour héberger son code source. Jusque-là, le projet utilisait Subversion (svn pour les intimes), un logiciel de suivi de version créé en 2000, en guise de source principale, même si le code était déjà dupliqué sur GitHub en guise de sauvegarde.

Le projet WebKit sur le site web de GitHub.

Apparu en 2005, Git n’existait même pas quand Apple s’est lancée dans la création d’un moteur de rendu web, en juin 2001. Subversion était à l’époque un choix logique, mais en matière de suivi de version, Git s’est imposée comme la référence, ce qui justifie en grande partie le choix de faire cette transition. Les développeurs de WebKit avaient déjà tendance à utiliser la copie stockée sur GitHub pour travailler au lieu de partir de la version originale stockée sur le serveur Subversion, ce qui a certainement contribué à la décision.

Git présente un autre avantage : c’est un outil de suivi de version distribué, où chaque serveur et client a l’intégralité des données. Cela apporte plusieurs gros bénéfices pratiques, comme la possibilité de passer rapidement d’une branche à l’autre, ou de remonter le temps facilement, sans avoir à solliciter le serveur à chaque fois. En contrepartie, les identifiants uniques associés aux commits (modifications du code) sont aléatoires et non plus séquentiels comme avec svn, ce qui a nécessité quelques ajustements.

Quant à GitHub, c’est aussi le choix par défaut pour l’écrasante majorité des développeurs. Le service géré par Microsoft est utilisé par la plus grande communauté de développeurs et c’est la plateforme de prédilection pour un projet open-source, justifie l’article de blog qui met aussi en avant l’API complète de GitHub, bien utile pour les tâches d’automatisation liées à WebKit.

Le moteur de rendu web d’Apple est ouvert et tout le monde peut participer, même s’il ne faut pas se faire trop d’illusion si vous voulez le mener dans une direction qui ne convient pas à l’entreprise. C’est d’ailleurs sans doute en partie pourquoi Google a fini par abandonner WebKit au profit de son propre moteur de rendu, un fork (clone), avec Blink.

avatar Jeckill13 | 

Jusqu’à présent j’utilise Git avec GitHub ou BitBucket. Je n’ai jamais testé Subversion… quels avantage et inconvénients comparé à Git ?

avatar Derw | 

@Jeckill13

Cela fait 10 ans que je n’ai pas utilisé SVN et je ne suis pas un spécialiste dans ce domaine, ma réponse ne sera donc pas forcément la meilleure… Toutefois, je dirais que les seuls avantages de SVN sur GIT sont son traitement linéaire et sa hiérarchie forte du serveur. C’est un avantage pour la compréhension (GIT est beaucoup plus complexe a appréhender) et pour la maîtrise (c’est plus compliqué de faire n’importe quoi). Mais en fait, ces « avantages » sont des « avantages » uniquement pour ceux qui cherchent la « simplicité » et la « verticalité ». Dans les fait, GIT permet beaucoup plus de choses, apporte plus de souplesse et, finalement, permet plus de sécurité si on le maîtrise bien. D’ailleurs, GIT a été inventé parce que les autres systèmes de versionnage ne satisfaisaient pas ses inventeurs, qui ont donc décidé de repartir de 0 avec une autre philosophie (la décentralisation)…
Voilà, ce que j’en ai compris…

avatar raoolito | 

je viens de comprendre que l'on utilise SVN du coup :)
au moins je serais moins bete

avatar JohnWalker | 

@raoolito

"au moins je serais moins bete"

Chéri chaque jour tu peux t’améliorer.

Don’t be a garbage collector.

Feed your life!

avatar chrisfrank | 

@Jeckill13

Derw a totalement raison ! Git est bien meilleur car décentralisé. Si l’un des développeurs se trompe sur la gestion des branches sur sa machine, les autres ne sont pas impactés tant qu’il n’a pas push.
Sur SVN, c’est le serveur qui fait foi. Un commit et un push, c’est la même chose pour lui. Tu te trompes… Tant pis! Revert et merge… Probablement pas de pull request. Hardcore quoi!

avatar Lemmings | 

@Jeckill13 : La seule vraie chose à savoir sur Git vs le reste des solutions, c'est sa force de pouvoir modifier l'historique. Le rebase et autres sont LA force que n'ont pas les autres.

SVN n'est finalement qu'une version mature et bien plus fiable que ne l'était CVS, il en reprend d'ailleurs quasiment tous les codes.

Git a été inventé et développé par Linus Torvald pour gérer le kernel Linux, c'est donc un système pensé pour la décentralisation et le travail collaboratif massif qui est bien plus difficile à faire avec SVN.

avatar Mrleblanc101 | 

@Jeckill13

Rien, svn c'est mort depuis longtemps

avatar marc_os | 

C’est d’ailleurs sans doute en partie pourquoi Google a fini par abandonner WebKit au profit de son propre moteur de rendu, un fork (clone), avec Blink

Mais oui bien sûr.

avatar lmouillart | 

Pourtant c'est totalement le cas. Apple et Google n'étaient pas forcément d'accord sur l'évolution du moteur.

A noter que chez Google (Blink) c'est pareil en dehors du trio macOS, Windows, Linux, et des productions Google Android, Fushia, ChromeOS point de salut.
N’espérez pas voir intégrer des plateformes comme les BSD, Tizen, Haiku-OS ou n'importe quoi d'autre. Sur ce point Apple est beaucoup plus souple et ouverte et c'est pour cette raison qu'un nombre important de projets libres et de Samsung reposent sur Webkit plutôt que Blink.

avatar PtitXav | 

@lmouillart

Avec SVN on peut très bien gérer en local. C’est ce que xCode permettait avant le passage à git obligatoire.

avatar marc_os | 

Je déteste git.
La gestion des conflits est abracadabantesque, et il faut bien connaître toutes les subtilités des commandes. La ligne de commande est obligatoire pour tout projet compliqué avec moult branches et développeurs dessus.
SourceTree de Atlassian permet de faire les choses basiques, sinon ligne de commande obligatoire dès que ça se complique.

Pour moi le seul avantage de git c'est la possibilité de gérer un projet 100% en local, ce que ne permettait pas SVN qui nécessitait un serveur de sources. Pratique pour les projets "perso" où on est tout seul à coder.

avatar oomu | 

@marc_os

la ligne de commande git est pourtant étudiée pour être simple et explicative. Les messages d'erreurs donnent des conseils, et rappellent ce qui est assez souvent ce que vous vouliez faire.

Après, je travaille dans une entreprise où les ingénieurs répondraient "tout cli ? ben vi c'est une qualité".

notons qu'il existe des outils web et interfaces graphiques pour naviguer, cloner ou commit des projets git.

ce que j'apprécie de git c'est sa simplicité (en terme de mise en oeuvre: ssh ou protocole git, ou un git init dans un dossier local et pouf ça marche. En environnement Linux/Macos et même Windows qui a maintenant openssh de base à jour, ça tombe en marche tout seul quasiment).

avatar marc_os | 

@ oomu

> la ligne de commande git est pourtant étudiée pour être simple et explicative

Lors de la gestion d'un conflit, on peut soit faire un rebase soit un merge, avec des effets secondaires différents. Ça m'énerve, et je ne dois pas être doué parce qu'à chaque fois je perds du temps sur ce beans. Donc non, pour moi ce n'est pas simple ni explicatif. Pourquoi faire un rebase pour gérer un conflit ? 😳 Il n'y a rien d'explicatif en soit dans le nom.
Et pourtant, je ne suis pas rétif à la ligne de commande, ayant bouffé à une époque du vi et du regex.
La ligne de commande vs l'outil avec interface graphique, c'est le PC sous MSDOS vs le Mac Plus. Mais bon, ça flatte l'ego de certains collègues qui se sentent plus "geeks" que les autres.

avatar blopi4 | 

Perso je rebase jamais, je merge 😂

Et quand je merge une pull request sur GitHub / Gitlab / whatever, je squash et le seul historique qui restera sera celui de la pull request.

Garder en historique tous mes commits locaux me semble être d'aucun intérêt 😆

Après il y a gitkraken, meilleure gui git du moooonde.

On saluera vscode qui a le 3 pan merge comme Webstorm désormais.

avatar Derw | 

@blopi4

C’est chacun ses goûts 😉. Moi, c’est Tower mon outil GUI GIT préféré. SourceTree est très mal foutu JE trouve, niveau UX. Git Kraken, c’est joli, mais ayant déjà mes marques dans Tower, je ne m’y retrouvais pas…

avatar Derw | 

@marc_os

Oui, Git, par son côté décentralisé, est plus complexe à comprendre. Ms au moins, il ne peut pas y avoir de conflit en théorie sur le serveur ; les conflits se créent en local. Mais moi qui n’ai pas eu une formation dev, j’ai parfois du mal… En ce qui me concerne, tous mes conflits je les gère soit via des diff, soit des revert, soit par des force push (sur une branche perso bien sûr)…

avatar madaniso | 

Git ❤️

CONNEXION UTILISATEUR