Astuces et conseils Git

• Même les utilisateurs de Git de longue date peuvent facilement passer à côté de fonctionnalités méconnues, ce qui remet en cause l’idée que la maîtrise avancée de la ligne de commande serait généralisée
• Contrairement à la génération venue de SVN ou CVS, les développeurs ayant toujours utilisé Git ont eu moins d’occasions d’apprendre certains usages avancés
• Au fil du temps, Git a continué d’ajouter de petites fonctionnalités utiles, et ces évolutions peuvent avoir une valeur pratique dans certaines situations
• Pour les utilisateurs intermédiaires à avancés, les sujets sur les fonctionnalités anciennes mais utiles, les ajouts récents et les grands dépôts/monorepos sont répartis en une courte série en 3 volets
• Revenir sur des fonctionnalités invisibles lorsqu’on s’en tient à ses habitudes d’utilisation de Git peut aider à gérer plus efficacement le travail quotidien sur les dépôts

---

Pourquoi se replonger dans Git

• En préparant récemment des présentations sur Git et GitButler, l’auteur a constaté que de nombreux développeurs avaient encore des angles morts sur Git
• Autrefois, il donnait des présentations avancées sur Git, mais depuis une dizaine d’années il partait du principe que les gens connaissaient déjà les fonctionnalités avancées en ligne de commande
• La génération de développeurs qui n’a connu que Git n’a pas eu à migrer depuis des outils comme SVN ou CVS, ni à réapprendre d’anciens concepts
• Git aussi a évolué avec le temps et a acquis de nouvelles fonctionnalités ; la plupart sont discrètes ou ciblées, mais elles peuvent aider dans le travail réel
• La série de billets s’appuie sur la présentation FOSDEM 2024 little known Git stuff

Une série d’astuces Git en 3 volets

• Elle s’adresse aux utilisateurs intermédiaires à avancés de Git et couvre des fonctionnalités que même des utilisateurs chevronnés ont pu manquer
• Plutôt que de tout mettre dans un seul article, le contenu est réparti en trois billets courts, chacun centré sur quelques thèmes
• Sujets inclus :
  • Oldies but Goodies : des fonctionnalités Git anciennes mais toujours utiles
  • Some Subtle New Things : des changements subtils ajoutés récemment à Git
  • Really Large Repositories and Monorepos : des sujets liés aux très grands dépôts et aux monorepos
• Le premier billet se poursuit avec Oldies but Goodies

[GN⁺]

Avis sur Hacker News

• En tant qu’auteur, il reconnaît avoir appris une grande partie de ces choses assez récemment. Les fonctionnalités liées aux grands dépôts ont été intégrées progressivement au cœur de Git par Microsoft et GitHub ces dernières années, si bien qu’il est difficile de trouver une ressource qui rassemble en un seul endroit ce qu’ils ont fait.
  Il dit aussi avoir eu des échanges intéressants avec les gens de Mercurial, et qu’ils obtiennent récemment des gains de vitesse impressionnants en réécrivant certaines parties internes de Hg en Rust.
  Il envisage également une 3e édition de Pro Git, et invite les lecteurs à lui signaler ce qu’ils ont appris à la dure avec Git, ou ce qu’ils aimeraient savoir.
  • Vous le connaissez peut-être déjà, mais difftastic est un bon remplacement du diff de Git : https://difftastic.wilfred.me.uk/
    Parmi les alias gitconfig que j’utilise souvent, il y a fza, gone et root. git fza affiche les fichiers modifiés/nouveaux dans une fenêtre fzf, puis passe les fichiers sélectionnés à git add : https://github.com/junegunn/fzf
    git gone supprime les branches locales qui n’existent plus sur le distant, et git root affiche la racine du dépôt, ce qui est pratique pour revenir à la racine depuis un répertoire profond. Ces temps-ci, je l’utilise moins depuis que j’utilise zoxide : https://github.com/ajeetdsouza/zoxide
  • Dans la partie sur les différences d’espaces, il serait utile d’ajouter ignore-revs-file. On committe un fichier ignore-revs dans le dépôt, et la personne qui effectue un gros reformatage y ajoute le SHA correspondant afin d’éviter de casser git blame.
    https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revltrevgt
  • L’une des choses que j’ai apprises à la dure avec Git, c’est que les opérations comme les merges, les cherry-picks et les rebases ne fonctionnent pas à partir de snapshots, mais à partir de différences et de patches — plus précisément via des merges à trois voies. Pro Git met bien l’accent sur le modèle de stockage de Git par snapshots, mais si l’on ne pense qu’à ce modèle, cela peut devenir déroutant, surtout avec rebase.
    Par exemple, je ne comprenais pas pourquoi supprimer un seul commit pendant un rebase modifiait tous les commits suivants. Ce n’est qu’en réalisant que le stockage est basé sur des snapshots, mais que les opérations sont basées sur des différences, que j’ai compris le rebase. Mettre davantage l’accent sur ce point dans l’enseignement aiderait beaucoup.
• Je ne veux pas apprendre des tours de magie avec Git ; je veux l’utiliser de la façon la plus simple possible. Je veux juste pousser mon code, en finir avec Git, puis continuer à travailler.
  Je respecte les gens qui aiment Git, mais pour moi c’est simplement un outil que je dois utiliser.
  • Une partie de la complexité de Git vient du fait qu’il a été conçu à l’origine comme une plomberie de bas niveau (plumbing). L’idée était qu’une surface utilisateur plus conviviale (porcelain) viendrait se poser au-dessus du modèle de données de Git ; pour obtenir une UI simple et cohérente, c’est peut-être encore la meilleure direction aujourd’hui. Jujutsu et Got (game of trees) peuvent en être des exemples.
  • Je comprends ce sentiment, mais Git n’est pas si difficile que ça. Au-delà des checkout/commit/push de base, connaître quelques notions — surtout la réécriture de l’historique — peut améliorer fortement la qualité de l’historique des commits et aider les autres ingénieurs du projet à comprendre le fil des changements.
    Git semble être une constante appelée à durer longtemps dans l’industrie, et c’est l’un des outils que l’on manipule le plus souvent au quotidien en développement ; cela vaut donc la peine d’y regarder d’un peu plus près.
  • Certains détails sont inhérents au problème lui-même, d’autres non. Je pense qu’on a tendance à sous-estimer la difficulté intrinsèque.
    C’est pourquoi un certain niveau de complexité dans Git me paraît acceptable.
  • Cela ressemble un peu à quelqu’un qui dirait ne pas vouloir apprendre la programmation et vouloir utiliser un ordinateur de la manière la plus simple possible : juste dire ce qu’il veut faire, puis en finir.
  • L’interface de Git ressemble à une abstraction qui fuit. Je ne voulais pas apprendre des tours de Git, mais j’ai fini par en savoir plus que je ne l’aurais souhaité.
• Je viens d’apprendre l’existence de core.fsmonitor. Du point de vue des grands monorepos, j’aimerais qu’il existe une option de reprise pour git clone.
  Dans les années 2000, en essayant de cloner le dépôt du noyau avec une connexion à faible bande passante, j’ai rencontré le même problème ; après avoir demandé de l’aide sur la mailing list, quelqu’un a fini par mettre tout le dépôt en tar compressé sur son site personnel, ce qui m’a permis de le récupérer.
  Même aujourd’hui, si le VPN de l’entreprise se coupe brièvement, le même problème arrive parfois lors du clonage de gros dépôts. Imaginez avoir téléchargé 95 % d’un dépôt Windows de 300 Go, puis perdre le Wi-Fi un court instant.
  Il est étrange que Git et Docker, les deux outils parmi les plus gourmands en bande passante dans les stacks de développement modernes, ne prennent pas correctement en charge la reprise des téléchargements.
  • Ce que vous voulez ressemble beaucoup à git bundle. Le bémol, c’est qu’il faut que quelqu’un ait créé le bundle au départ.
    https://git-scm.com/docs/git-bundle
  • On pourrait probablement faire un clone superficiel, puis l’étendre en plusieurs étapes. Cela dit, le protocole fetch/push s’attend en général à des dépôts plus petits, ou à une très bonne connexion Internet et à de bons serveurs.
• Très intéressant. J’aimerais voir qui parviendra à résoudre, avec une interface plus simple, le problème où plusieurs personnes contribuent à différentes releases, fonctionnalités et hotfixes, taguent des releases, puis reviennent dans le passé pour chercher des bugs.
  C’est un peu comme vouloir un langage de bas niveau qui masque la complexité du système : les deux sont en réalité presque mutuellement exclusifs. Git est satisfaisant et pas si difficile à apprendre ; en partie, il faut simplement apprendre Git.
  • C’est pour cela que je recommande fortement GitKraken. Je le fais avec prudence, car c’est un produit payant, mais j’ai essayé de nombreux outils et aucun ne libère autant la puissance de Git que GitKraken.
    Il retire l’effet de boîte noire que beaucoup de développeurs ressentent dans le terminal, met le graphe au premier plan et rend les opérations de rebase visuellement naturelles, au point que Git devient amusant.
    La maîtrise de la CLI reste précieuse, mais c’est frustrant de voir des développeurs avec dix ans d’expérience bloquer sur des problèmes de base, ou abîmer l’historique d’un projet parce qu’il existe cette ambiance selon laquelle « un vrai ingénieur doit utiliser uniquement la CLI Git ».
    Aujourd’hui, même quand quelqu’un utilise la CLI, je lui dis de garder le graphe sous les yeux toute la journée dans une autre fenêtre. C’est possible gratuitement avec VS Code, JetBrains, et même en CLI.

quand un membre de l’équipe fusionne une PR, je le vois aussitôt et je rebase ma branche, donc elle reste toujours à jour sur la base de main, ce qui évite l’enfer des merges et les affreux commits “fix conflicts”

• En cherchant les 10 fichiers les plus modifiés depuis leur création hier, je suis tombé sur https://github.com/tj/git-extras/blob/main/Commands.md
  Il y a beaucoup de commandes Git supplémentaires utiles

  • git-extras, c’est bien. Un autre outil intéressant est git absorb : https://github.com/tummychow/git-absorb

• Je ne comprends pas bien pourquoi la plupart des développeurs tiennent absolument à la CLI Git, alors que des clients UI modernes comme GitKraken sont tout à fait utilisables et utiles : https://www.gitkraken.com/

  • La connaissance de la CLI mène à l’écriture de scripts, et les connaissances Git acquises via les scripts se répercutent ensuite sur l’usage quotidien. Je n’ai pas envie de me retrouver démuni simplement parce que je dois utiliser la CLI quand je me connecte en SSH à un Raspberry Pi qui me sert de serveur
    Je ne suis pas totalement opposé aux GUI, mais pour l’instant la CLI est plus efficace, et je n’ai pas envie de passer du temps à chercher une GUI qui remplisse les conditions suivantes
    Elle doit être agréable, être une application native et non un vieux navigateur web embarqué, ne pas avoir de télémétrie ou l’avoir désactivée par défaut, être entièrement open source, et on doit pouvoir raisonnablement s’attendre à ce qu’elle existe encore dans 5 ans
    Elle ne doit pas non plus rendre les choses plus confuses. Dans une ancienne entreprise, je devais utiliser Visual Studio, et un bouton qui voulait en réalité dire “marquer le conflit comme résolu” portait l’intitulé inquiétant “Accept merge”
    Il ne faut pas embrouiller les gens qui s’attendent déjà à ce qu’un mot précis ait un sens précis, et il est difficile de faire confiance à un bouton “Commit changes” qui, sous prétexte d’être serviable, pousse aussi à distance
  • La CLI est aussi tout à fait utilisable. J’utilise aussi des plugins d’éditeur, mais si je suis déjà dans la ligne de commande, je le fais là
    Si je dois basculer vers un autre programme juste pour faire un commit, cela réduit ma motivation à committer souvent
  • Sauf problème très spécifique, je limite au minimum ce que je fais avec Git. Dans mon cas, c’est en gros push, pull, checkout, donc utiliser une GUI me semble excessif
  • Même si elles ont l’air propres, les interfaces graphiques deviennent trop facilement distrayantes. Au final, cela ressemble à une question de préférence personnelle, et la CLI est rapide, mais la courbe d’apprentissage est raide
    Même quand on utilise Git en CLI, la plupart du temps il ne s’agit pas de choses particulières, seulement de quelques commandes, et je note dans un fichier texte les astuces ou trucs que je n’utilise pas souvent

• Je connaissais -committerdate, mais je ne savais pas qu’on pouvait le définir comme tri par défaut, et c’est très utile. Quelques remarques
  git columns devient assez déroutant quand tout ne tient pas à l’écran et qu’il faut faire défiler ; ce serait bien d’avoir des numéros
  git maintenance a l’air bien, mais je rebase beaucoup, donc ça m’inquiète. Je me demande si on perd les objets détachés plus vite qu’avec gc. Je vois que gc est désactivé, mais ce n’est pas clair
  À propos de git blame, il existe un script peu connu mais utile : https://github.com/gnddev/git-blameall. Il est tellement méconnu que j’ai dû le porter moi-même vers Python 3, et je ne suis même pas développeur Python

  • Dans la maintenance planifiée, gc est désactivé. Quand on exécute explicitement maintenance run, il est activé comme tâche
    Les objets détachés ne sont pas collectés plus vite qu’avec gc. Au final, c’est simplement parce que cela exécute gc
  • Je me demande si un tri inversé est possible. La solution simple au problème des branches qui sortent de l’écran semble être de mettre les branches les plus récentes à la fin. C’est ce que je fais avec un script utilisateur
  • On ne les perd pas plus vite. Cela récupère seulement plus souvent les données depuis le remote et repacke les données. Si GC est désactivé, les données ne sont pas supprimées
    git-blameall a l’air pas mal, je vais l’essayer

• J’ai beaucoup simplifié mon flux Git avec quelques alias qui fonctionnent dans plusieurs environnements
  git synced synchronise la branche actuelle par rebase avec son upstream s’il existe, sinon avec origin. Il utilise master ou main, avec une préférence pour main
git pub publie les changements sur le remote origin et utilise un force push avec lease
  git pr ouvre l’URL de PR appropriée sur GitHub, sans nécessiter le client GH. Si un upstream est défini, la PR est envoyée vers celui-ci
  git hub ouvre la page GitHub du dépôt
  https://softwaredoug.com/blog/2022/11/09/idiot-proof-git-aliases.html

  • Je me demande pourquoi il a choisi cette étrange flèche poilue comme séparateur

• J’ai arrêté de faire semblant de savoir ce que je fais et j’utilise des outils Git visuels. Des choses comme SmartGit ou l’outil intégré à IntelliJ. Les “héros de la ligne de commande” Git me semblent surtout être dans la démonstration
  La couche de commandes destinée à l’utilisateur peut être horriblement déroutante. Par exemple, Yours et Theirs peuvent vouloir dire exactement l’inverse selon le contexte
  Il n’y a ni style ni thème commun à toute l’interface utilisateur, donc il faut une nouvelle couche visuelle pour éviter de rendre les gens fous

  • Pareil pour moi. J’aime pouvoir toujours voir les différences et vérifier visuellement, d’un coup d’œil, ce qui va se passer. Pas besoin non plus d’exécuter plusieurs commandes supplémentaires
    Je connais l’application et Git en général juste autant que nécessaire pour mon travail, et si j’ai rarement besoin de plus, je peux chercher. En plusieurs années d’utilisation, cela n’est arrivé qu’une ou deux fois
  • Pour le travail quotidien, j’utilise toujours un outil Git visuel, en particulier Tortoise Git
    Même pour les opérations complexes visant à corriger les erreurs d’autres personnes ou les miennes, je commence par utiliser un outil visuel pour examiner l’historique, les commits, le reflog et les diffs, afin de comprendre ce qui s’est emmêlé et ce qui peut être récupéré
    S’il n’y a qu’un commit auquel revenir, je fais un reset --hard, et s’il faut combiner des éléments de plusieurs commits, j’utilise généralement la ligne de commande

• Les deux ne sont pas mutuellement exclusifs. Pour des choses comme les diffs ou les conflits, je n’utilise que des outils visuels, mais j’ai beaucoup appris en étudiant les objets de commit, le reflog, ce que fait le rebase en coulisses, le rebase interactif, les resets hard/soft, etc.