DIP S01E03 – git, fusions, remotes et astuces avancées

Vendredi 16 novembre, nous étions 5 à nous réunir pour ce second Meetup dédié à git. J’étais venu avec ma présentation mais comme certains avaient des questions issues du précédent meet-up sur git, nous avons commencé par y répondre, en reposant largement sur Visualizing git, un outil de représentation visuel des commandes, fort pratique pour expliquer ce qui se passe.

Visualizing git

Au programme de ces échanges, et de la présentation qui a suivi : les différents types de fusions (merges) et la meilleure manière d’aboutir à une situation de fusion idéal (des git rebase successifs pour aboutir à une situation de fast-forward, aka git merge --ff-only).

Bien sûr, rien de tout ça n’est possible sans apprendre, d’abord à nettoyer son historique. Car si, comme moi, vous êtes un serial killer commiter, hors de question de proposer à vos collègues de fusionner votre code si vous n’avez pas un peu soigné votre historique d’abord. Nous avons donc un peu creusé l’utilisation du rebase -i <commit>, mais aussi de git add -p pour ciseler de plus jolies contributions dès le départ. Enfin, nous avons cueilli des contribution avec git cherry-pick et avons un peu parlé du garbage collector.

Ce point étant abordé, comment vraiment travailler avec des collègues ? Nous avons parlé du caractère profondément dématérialisé de git, et ce qu’il apporte dans une organisation centralisée, vous permettant par exemple de déclarer à la fois votre dépôt distant sur origin mais également le dépôt à partir duquel vous avez réalisé un fork pour récupérer les évolutions de ce projet principal et réaliser vos rebase en amont d’une PR (Github) ou MR (Gitlab).

Ce fût l’occasion d’introduire les git hooks, qui sont au cœur de l’intégration continue (le principe est de lancer automatiquement des commandes en amont de certaines actions pour les valider, ou après certains événements pour y réagir. Cela permet, par exemple, de vérifier le respect d’une convention de code avant une contribution, ou de lancer la livraison du site côté serveur après un push). J’en ai également profité pour montrer une autre commande méconnue, mais qui peut sauver une session de debug : git bisect, à l’aide d’un projet d’exemple.

Je pensais que nous en aurions pour moins de temps que la première session, mais tout cela nous a tenu en haleine pendant près de deux heures. Je me rends compte en rédigeant ce compte-rendu que je n’ai pas cité l’excellent « Git par la pratique », traduction du « Git for humans » de David Demaree. Si vous cherchez un livre accessible pour retrouver les bases de git, je vous le recommande !

"Git par la pratique", de David Demaree, chez Eyrolles

Boris

Ce projet est maintenu par dev-in-perigueux