Que s’est-il passé ?

Les 2 et 3 Février derniers, avait lieu la conférence Git Merge 2017, à l’EGG Bruxelles. Après une première journée à guichets fermés, ce n’est qu’au deuxième jour que Tapptic a pu y assister, et vous livrer ce retour. Cédric Goffoy et Sofiane Hassaini y étaient, et tenteront de vous partager le contenu de cette conférence, comme si vous y étiez ! Une douzaine de participants a répondu à l’appel, présentant différents sujets. Nous nous concentrerons ici sur ce que nous pensons être intéressant à l’avenir.

 

Les 10 pires dépôts à héberger sur GitHub

Carlos Martin Nieto, de Github, était présent pour nous présenter les 10 pires dépôts qu’ils ont eu à gérer, et comment leurs outils et approches ont évolué, afin de pouvoir gérer les cas et attentes les plus inattendus. Il est intéressant de noter que, dans la plupart des cas, le problème était éducationnel, et qu’une fois les bonnes manières de travailler apprises, le problème disparaissait.

 

En d’autre termes, beaucoup des problèmes rencontrés concernaient la quantité de données et la manières dont les utilisateurs essayaient de les récolter de manière massive et régulière, au lieu de diviser le travail et d’organiser les accès, pour au final mettre au point un framework propre.

Bien que les projets que Tapptic ne requièrent aucun fichier ou quantité de fichier de cette taille, il peut être bon de commencer ou continuer dès lors à appliquer ce que nous pourrions appeler de bonnes pratiques : des répertoires plus petits et répertoriés, des requêtes pull, efficaces et une bonne répartition. L’intervenant suivant a évoqué directement les problèmes de chargement : Saeed Noursalehi de Microsoft est intervenu, et a notamment mentionné la taille phénoménale de leur dépôts (270Gb pour Microsoft, par exemple).

 

Il faut néanmoins prendre aussi en compte le nombre de personnes ayant besoin d’un accès et des droits de modification de ces dépôts : can vous avez 35 000 utilisateurs, que pourrait-il se passer ? La réponse est simple : vous voulez une copie clone ? Revenez dans 12 heures. Un statut Git ? Allez prendre un café, vous avez 8 minutes à tuer. Vous voulez faire un check-out ? Félicitations, vous avez une matinée de libre. La solution que Microsoft a été de développer une solution maison, superposée à Git, mais assez transparente pour que les utilisateurs de Git ne se sentent pas dépaysés. Cette solution est le GVFS, un système de fichiers systèmes virtuel, qui réduit les temps de chargements. Bien qu’encore en développement, vous pouvez dores et déjà y jeter un coup d’œil

Ce système de fichiers GVFS ne télécharge que les fichiers nécessaires à un moment précis. De ce fait, certaines commandes sont bien plus rapides, tels qu’un checkout ou un statut git. Annoncé comme open source, vous pouvez trouver des articles de blog plus techniques déjà.

Un lien vers le dépôt GVFS GitHub : https://github.com/Microsoft/GVFS

Qu’est-ce qui cloche avec Git ?

Santiago Perez De Rosso du MIT est ensuite intervenu pour nous raconter leur approche et tentatives de réparations de problèmes de conception de Git. Après des recherches approfondies, 3 problèmes majeurs ont été recensés comme rencontrés par la plupart des utilisateurs (novices), sans process clair et précis sur le traitement à apporter.

 

  • Switch branch on a non-clean state.
  • Fix detached HEAD
  • Handle untracked files

 

Répéter chaque point abordé serait trop long, sachant qu’il s’agit d’une conférence de deux heures, et que Mr Perez de Rosse lui-même a effectué un travail splendide à ce propos : http://people.csail.mit.edu/sperezde/onward13.pdf

 

Ce document illustre la philosophie derrière l’outil qu’ils ont développé, afin de dépasser certains illogismes de conception de Git. Cet outil, appelé Gitless, est dès lors téléchargeable, vous pouvez donc l’essayer. Il pourrait être une manière pour les novices d’apprendre à utiliser plus aisément, ou au quotidien. Il faut garder à l’esprit également que Gitless est conçu comme étant une surcouche de Git, donc il est toujours possible de retomber sur l’interface intiiale de Git. Il est également possible de s’en servir quand d’autres utilisateurs font appel à la version classique de Git. Toute la documentation concernant cette interface est disponible ici : http://www.gitless.com

Implanter Mercurial chez Facebook, vu de l’autre côté

Durham Goode, de chez Facebook, a été témoin des difficultés rencontrées par sa boîte, qui atteignait des proportions énormes. Bien qu’il n’ait pu communiquer aucun chiffre, il reste persuadé que le dépôt unique de Facebook est le plus grand qui existe, et qu’il n’est pas dépourvu de problèmes.

Facebook utilise Mercurial but the point still stands when it comes to scaling projects. When the repo size and the amount of users increase exponentially, if you have not planned ahead, you’re up for your share of trouble.

The Facebook approach is the following :

  • Monorepos ;
  • No feature branch ;
  • Rebase, no merge ;
  • Single commit per push ;
  • Code review on each commit.

No more complex branching, everytime a user wants to push a commit to Master, he enters a secure process of reviewing (human reviewing and software reviewing) ensuring that when the push finally is accepted and goes through, everything will be ok and every action taken against the commit is logged.

Better than that, some checks are triggered at the commit stage, allowing the user to avoid the most generic mistakes he can be confronted to when committing his work, increasing the value of the time spent for human reviewing further down the line.

If you want a more technical and precise approach , you can find here the associated blog written by Durham Goode himself : Scaling Mercurial at Facebook.

Git Aliases of the Gods!

We didn’t see the time pass by and as we came back from the last break of the day, a lighter kind of lecture was about to start : Git and the aliases.

Even though many git commands are one liners, you may be confronted to more complex commands and Tim Pettersen from Atlassian is confident that using Aliases is the best way to deal with them. The simple example he gave was the stash command. If you didn’t know, there are 4 of them, including more or less type of files (only index, classic stash, stash including untracked and stash all).

Instead of writing « git stash –including-untracked » for example, he aliased the commands to reflect the amount of data he wants to include from the least to the most : git stsh, git stash, git staash and git staaash. That’s a silly example but you get the philosophy behind.

Add to that that you can share your aliases through a config file and you get a portable system for your team to use.

Git for Pair Programming

The last meaningful lecture of the day was about the pair programming and how Git currently fails to handle this work style. For those who may not know what’s pair programming, imagine 2 developers, one computer (nothing weird I promise). You can have 2 keyboards and 2 mice or just share one.

The philosophy here is to have a driver and a copilot and relies mostly on communication. Developer A handles the keyboard and Developer B reviews code in real time, commenting and offering alternative solutions as they come.

After a while, the two developers switch roles and so on for the day. There are immense advantages in doing that :

  • Real time reviewing, reducing bug apparition and bug tracking, thus QA workload ;
  • Knowledge sharing, allowing a junior profile to learn by watching a more experienced developer in action or even two experienced developers sharing their own different knowledge and experiences ;
  • Team building, by communicating a lot, allows the team members to bond ;
  • Time saving, that seems counter-intuitive due to having 2 people seemingly doing the work of one but practically, it’s been proved that by reducing the bug apparition and the trial and error code, the job is done quicker and cleaner.

To promote that work style, Cornelius Schumacher was there to let us sneak a peak at a feature he’s developing, allowing to co-sign commits and easily identify who was the driver and the copilot for a specific commit, it is still a WIP and if you’re interested, you can embark with him and collaborate to the project.

This tool is called Git Duet and let you specify a team inside git config file. After that for each commit you can select authors whose worked on this one. You can find here the link to the GitHub repo : https://github.com/git-duet/git-duet

Keep in mind that this is WIP, so feel free to give feedbacks, pull requests, etc.

 

Sofiane Hassaini

Cédric Goffoy

Android developers @ Tapptic