Journal Des emojis dans votre historique Git (ou tout autre CVS) ?

Posté par  (site web personnel, Mastodon) .
Étiquettes :
15
10
mai
2023

Salutations, Nal,

Depuis quelques années on peut facilement mettre des emojis un peu partout.

Certains se sont dit qu’on pouvait les utiliser en premier caractère des messages de commit Git, ce qui offre divers avantages et inconvénients qu’on va détailler un peu plus loin. L’idée de base est que l’emoji offre un « résumé » très lisible de l’intention du commit, sans avoir à lire le message pour avoir une idée générale de ce qui va se passer dans le commit.

La pratique s’est assez développée pour qu’un site, gitmoji, propose plein d’emojis pour différents contextes. Pour l’avoir utilisé dans divers projets, je vous propose un petit résumé des avantages et inconvénients de la pratique :

Avantages

  • C’est un vrai gain de lisibilité : juste en voyant la liste des nouveaux commits au pull, j’ai une idée des modifications qui vont m’impacter. Idem pour une opération comme un rebase, juste en voyant la liste des commits, j’ai une idée de s’il va y avoir beaucoup de risques de conflits ou non.
  • Ça aide à séparer les commits : si je me dis que je devrais mettre plusieurs emojis, c’est en général que je suis en train de commiter des choses qui devraient être dans des commits séparés.
  • Certains râlent par principe en voyant des emojis (donc ça fait fuir les aigris).

Inconvénients

  • Le langage des emojis n’est pas si universel que ça, si les emojis sont mal définis ça peut ajouter de la confusion. La liste de gitmoji est probablement trop complète, un sous-ensemble propre au projet (et documenté par exemple dans le readme) semble plus efficace. Ce point est encore plus important dans une équipe multi-culturelle.
  • Selon les outils, les emojis peuvent être difficiles à lire (surtout pour qui travaille sous Windows, où les emojis sont assez horribles).
  • Certains râlent par principe en voyant des emojis (donc ça peut faire fuir de bons contributeurs).

Et vous, est-ce que vous avez utilisé un tel dispositif ? Si oui, qu’en avez-vous pensé ? Si non, est-ce que ça vous intéresse ?


Ce journal est placé sous licence CC-0 1.0.

  • # Jamais pratiqué

    Posté par  . Évalué à 7.

    Tu as peut être omis que c'est fait pour appliquer le conventional commit qui fini des types de commits sous la forme d'abréviations.

    Je sais que ça existe, mais je ne l'ai jamais utilisé. Dans la pratique comment ça se passe, tu a un outil pour avoir le smiley ou c'est par copier/coller avec le site ?

    J'imagine que ça permet aussi de gagner quelques caractères dans la première ligne de message de commit qu'il est conseillé de garder sous les 50 caractères.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Jamais pratiqué

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Effectivement j’ai oublié de préciser que c’est une forme de conventional commit. On faisait du copier/coller.

      La connaissance libre : https://zestedesavoir.com

    • [^] # Re: Jamais pratiqué

      Posté par  (site web personnel) . Évalué à 5.

      tu a un outil pour avoir le smiley ou c'est par copier/coller avec le site ?

      Pardon pour la question idiote mais on ne peut pas facilement saisir d'emoji sous linux ?
      Oui ca fait un moment que mes machines de taff sont sous mac donc c'est super simple (d'autant plus que c'est mappé sur une double frappe de ma touche échappe qui est en gros à la place du caps lock, donc accessible)

      Sinon sur le sujet en lui même je l'ai utilisé sur plusieurs projets sur les 6-7 dernières années en gros. C'est bien mais j'en suis revenu, et maintenant je reste avec du conventional commit plus classique et ca marche bien.

      • [^] # Re: Jamais pratiqué

        Posté par  . Évalué à 3.

        Oui ca fait un moment que mes machines de taff sont sous mac donc c'est super simple (d'autant plus que c'est mappé sur une double frappe de ma touche échappe qui est en gros à la place du caps lock, donc accessible)

        Tu peux :

        • comme tu le fais mapper des touches comme tu l'entends
        • taper la valeur unicode correspondante
        • avoir un clavier virtuel qui t'y donne accès
        • les copier-coller depuis ce que tu veux
        • taper simplement les types et laisser les hooks faire le remplacement
        • te créer un alias qui prépare ton message de commit avec le smiley que tu veux

        (et oui toutes ces options fonctionnent sur tous les OS)

        Je n'utilise personnellement pas fréquemment de smileys, je questionne les pratiques. C'est puérile de se prendre ce genre de remarque derrière.

        j'en suis revenu

        Pourquoi donc ?

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Jamais pratiqué

          Posté par  (site web personnel) . Évalué à 3.

          C'est puérile de se prendre ce genre de remarque derrière.

          Rien de puérile ici je demande juste comment ca se passe sous linux aujourd'hui. Sous mac j'ai directement accès à une méthode de saisie des emoji et autres caractères spéciaux très facilement. La dernière fois que j'ai utilisé des workstation linux c'était très loin d'être le cas. Et j'ai l'impression que c'est toujours le cas…

          j'en suis revenu

          Pourquoi donc ?

          Parce que c'est marrant si l'emoji est toujours affichée, lorsqu'elle ne l'est pas pour une raison où un autre (genre un outil qui ne l'interpète pas) alors c'est beaucoup moins intéressant.
          Et dans ce cas je préfère les conventional commits de base.
          Aussi il est plus facile de convaincre tout une équipe d'utiliser du conventional commit texte qu'emoji. Et tout l'intérêt de ce genre de pratique c'est quand tout le monde le fait.
          Enfin j'ai aussi des outils qui utilisent conventional commits pour automatiquement générer les bons bunp de version quand on release, ils ne fonctionnent pas avec les emojis.

          • [^] # Re: Jamais pratiqué

            Posté par  . Évalué à 3.

            Sous mac j'ai directement accès à une méthode de saisie des emoji et autres caractères spéciaux très facilement.

            Tu entends quoi par là exactement ? Parce que c'était l'objet de ma question. Demander comment tu fais et avoir comme réponse "ah toi tu sais pas faire" je trouve effectivement ça puéril. D'autant que je n'avais même pas parlé d'OS.

            Parce que c'est marrant si l'emoji est toujours affichée, lorsqu'elle ne l'est pas pour une raison où un autre (genre un outil qui ne l'interpète pas) alors c'est beaucoup moins intéressant.

            Ah sous Mac les emoji ne sont pas correctement affichés ? 😜

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: Jamais pratiqué

              Posté par  (site web personnel) . Évalué à 2.

              Sous mac tu as un raccourcis clavier par défaut et tu as directement la fenêtre de clavier des emoji qui apparait https://support.apple.com/fr-fr/guide/mac-help/mchlp1560/mac

              Ah sous Mac les emoji ne sont pas correctement affichés ?

              C'est essentiellement une question d'outils.
              Et il m'arrive de voir des logs dans un terminal sur une autre machine et là les :rotating_light: ou :ambulance: ca me fatigue.

              • [^] # Re: Jamais pratiqué

                Posté par  . Évalué à 2.

                C'est essentiellement une question d'outils.

                Mon smiley n'a pas dû bien s'afficher dans ton navigateur. Il s'agissait plus de te renvoyer une réponse symétrique à t'a première qu'une vraie question. Je sais bien que ça dépend des outils.

                Sous mac tu as un raccourcis clavier par défaut et tu as directement la fenêtre de clavier des emoji qui apparait https://support.apple.com/fr-fr/guide/mac-help/mchlp1560/mac

                J’appellerais pas ça pratique du tout. Si pour chaque commit un peu propre je dois lancer un outil à côté et naviguer/chercher pour trouver celui qu'il me faut. Il n'a pas l'air d'être possible de créer une liste dédiée pour à minima moins avoir à naviguer et il n'y a pas l'air non plus d'avoir d'historique (genre les 10 derniers utilisés). Ce qui ne serait pas la panacée, vu que ce n'est pas stable, mais qui pourrait aider un peu.

                La page parle de l'utilisation à la touch bar, j'ai pas bien compris comment ça s'utilise, mais il me semblait que la popularité des touch bar était pas folle (et j'ai l'impression qu'ils ne vendent plus de machines équipées).

                Je préfèrerais amplement utiliser les templates de message de commits de mon IDE ou en hook git. C'est moins sexy et ça marche quelque soit l'OS, mais une fois configuré, c'est bien plus confortable.

                https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                • [^] # Re: Jamais pratiqué

                  Posté par  (site web personnel, Mastodon) . Évalué à 3.

                  En fait sous Linux, soit avec un environnement de bureau basé sur GTK (exemple Xfce) soit avec Ibus, tu peux saisir le code Unicode de n’importe quel caractère en le faisant précéder par la combinaison de touche Ctrl + Maj + U. Ça devient vite un réflexe d’entrer le caractère de cette, ce que je fais par exemple en écrivant ce commentaire pour les apostrophes.

                  Et si on n’a qu’une petite série d’emojis, toujours les mêmes. On peut de faire un pense-bête qu’on finit par mémoriser sans y penser. C’est, effectivement plus simple que de lancer une application tierce. Encore faudrait-il que cela fonctionne avec les éditeurs de texte. Cela ne fonctionne pas avec tous.

                  « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

              • [^] # Re: Jamais pratiqué

                Posté par  (Mastodon) . Évalué à 3.

                En l'occurence l'outil adhoc (characters) de Gnome est supérieur dans le sens où sous chaque emoji il affiche son code. Si tu réutilises souvent les mêmes tu peux les taper directement via ctrl+shift+u suivi du code.

                Et le clavier en mode tactile permet d'y accéder aussi comme sur un mobile, c'est que je fais qua d j'utilise mon lenovo yoga. [1]

                [1] et des fois je touche bêtement l'écran de mes autres laptop par habitude…sans effet évidemment.

                • [^] # Re: Jamais pratiqué

                  Posté par  (site web personnel, Mastodon) . Évalué à 3.

                  Argh, j’aurai dû lire ça avant de commenter 🙂 pour dire la même chose grosso modo.

                  « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

                • [^] # Re: Jamais pratiqué

                  Posté par  . Évalué à 2.

                  Si tu réutilises souvent les mêmes tu peux les taper directement via ctrl+shift+u suivi du code.

                  Vous trouvez vraiment ce mode d'input pratique ? Ça permet de tout faire, mais ça n'a rien de pratique. Demander à l'utilisateur de connaitre des code abscons c'est pas fou.

                  Et pour un usage plus technique, je vois facilement un paquet de façon de ne pas avoir à mémoriser ces codes.

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                  • [^] # Re: Jamais pratiqué

                    Posté par  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 14 mai 2023 à 15:03.

                    L'utilisatrice lambda avec une très mauvaise mémoire des nombres que je suis trouve ça très pratique. Ça devient un réflexe. Ça se mémorise sans qu’on y pense de toute façon par la force de l’habitude. Et tu peux toujours comme je le disais plus haut, avoir un pense-bête à portée des yeux. En plus, il n’y a une foule de numéros Unicode à retenir c’est que le bouzin est mal fichu car l’abondance de symboles à retenir les rend inutiles. Beaucoup de gens, lambda, sous Windows utilisent ce genre de code au quotidien (mais le code décimal pour Windows).

                    Entre nous mémoriser des raccourcis clavier ou des commandes c’est très exactement la même chose. Je ne vois pas ce qui peut poser de problèmes aux développeurs.

                    « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

                    • [^] # Re: Jamais pratiqué

                      Posté par  . Évalué à 3.

                      Beaucoup de gens, lambda, sous Windows utilisent ce genre de code au quotidien (mais le code décimal pour Windows).

                      Et tu m'en vois désolé pour eux. Je connais des gens qui chez ST apprenaient par cœur des commandes de 4 caractères. Ils savaient que e1f5 c'était page suivante dans le pager de l'outil qu'ils utilisaient. C'est pas pour autant que ça me paraît être une bonne idée.

                      Entre nous mémoriser des raccourcis clavier ou des commandes c’est très exactement la même chose. Je ne vois pas ce qui peut poser de problèmes aux développeurs.

                      • Des raccourcis de 2 à 3 touches face à des code sur 4 octets.
                      • Des raccourcis dont une parti sont logiques, face à 1F603 (plus raccourcis)
                      • Intérêt de prendre du temps pour apprendre à taper 🚑️ face à quelques raccourcis qui servent à éditer du code (ton travail principal)

                      D'une manière générale, le mythe du développeur qui connais tous les raccourcis claviers est… un mythe. Les développeurs que j'ai croisé (et moi-même) en apprennent quelques uns et d'une manière générale c'est pas parce que quelqu'un en connaît quelques un que c'est une bonne idée de charger la charrue avec encore je ne sais combien en plus.

                      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                  • [^] # Re: Jamais pratiqué

                    Posté par  (Mastodon) . Évalué à 4. Dernière modification le 14 mai 2023 à 19:05.

                    Tu l'utilises pour ceux que tu utilises souvent et mémorise, plus rapide que chercher dans une liste. Mais l'outil pour les chercher existe aussi.

                    L'un n'empêche pas l'autre.

                    • [^] # Re: Jamais pratiqué

                      Posté par  . Évalué à 3.

                      Qui a dit que l'un empêche l'autre ?

                      Je dis juste que dire « ben oui il y a un moyen facile, tu apprends quel code correspond au caractère dont t'a besoin et comme ça tu n'a même pas besoin de te farcir gucharmap », ça me donne plus l'impression qu'on a fait ce qu'on a pu avec ce qu'on a mais que permettre de choisir puis d'insérer un caractère parmi 149k différents n'a pas encore trouvé de solution miracle.

                      Pour les smileys en particulier, tu as une extension gnome shell qui reproduit le comportement d'un clavier mobile. Ça me parait moins pire que gucharmap (mais sans permettre d'insérer le ф (qu'il ne faut évidement pas confondre avec Φ)).

                      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: Jamais pratiqué

        Posté par  (Mastodon) . Évalué à 4.

        Pardon pour la question idiote mais on ne peut pas facilement saisir d'emoji sous linux ?

        Tout dépend des environnements de bureaux, des émulateurs de terminaux utilisés, et/ou des configs utilisateurs.

    • [^] # Re: Jamais pratiqué

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 11 mai 2023 à 02:08.

      Dans la pratique comment ça se passe, tu a un outil pour avoir le smiley ou c'est par copier/coller avec le site ?

      Github et Gitlab supportent le format :nom de l'emoji: :

      • :bug: 🐛
      • :sparkles:

      Ils le supportent aussi dans les titres de PR/Issues.

      J'imagine que ça permet aussi de gagner quelques caractères dans la première ligne de message de commit qu'il est conseillé de garder sous les 50 caractères.

      Github et Gitlab vont comprendre l'emoji comme un seul caractères. Bon ça fait un comportement différent de git log, mais c'est pas trop grave.


      Perso, je préfère gitmoji à conventional commit. Une image est beaucoup plus facile à identifier que du texte. Et le format :bug: permet toujours de grep le git log assez facilement (un des avantages de conventional commit).

      https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

      • [^] # Re: Jamais pratiqué

        Posté par  . Évalué à 3.

        Github et Gitlab vont comprendre l'emoji comme un seul caractères. Bon ça fait un comportement différent de git log, mais c'est pas trop grave.

        Si les icônes ne sont pas toujours parlantes, j'ai l'impression que c'est pire avec leur nom et que la gymnastique est d'autant plus compliquée.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Jamais pratiqué

          Posté par  (site web personnel) . Évalué à 3. Dernière modification le 11 mai 2023 à 11:35.

          Leur nom est utilisé pour grep le git log, dans 99% des cas tu as la représentation visuelle (en explorant Github/Gitlab).

          Et parlante ou pas, au bout d'un certain temps (relativement court), cela devient un réflexe. C'est juste une question d'habitude (mais je comprends que les gens n'aiment pas changer leurs habitudes).

          Honnêtement :

          • 🐛 un bug
          • ✨ une fonctionnalité
          • 👷 de la CI/CD
          • 🔧 de la conf
          • 👕 fix de problème de linter
          • 📝 de la documentation
          • 🚧 du Work In Progress
          • ➕/➖ ajout/suppression de dépendance
          • ⬆️ mise à jour de dépendance
          • 📌 mise à jour du lockfile (yarn.lock, poetry.lock, Cargo.lock, …)
          • 🔖 bump de version du projet

          C'est ceux que j'utilise le plus, et c'est facile à retenir. Et quand j'en oublis, un petit détour par https://gitmoji.dev avec ctrl+f répond a ma question en 30s.

          Exemple ici : https://github.com/linkdd/tricorder/commits/main

          https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

          • [^] # Re: Jamais pratiqué

            Posté par  (site web personnel) . Évalué à 6.

            C'est pas plus simple et plus direct d'avoir:
            - [BUG]
            - [FEATURE]
            - [CICD]
            - [CONF]
            - [LINT]
            - [DOC]
            - [WIP]
            - [+DEP] ou [+DEP]
            - [DEP]
            - [LOCK]
            - [VERSION]

            Comme ça même pas besoin du Ctrl-f sur gitmoji

            • [^] # Re: Jamais pratiqué

              Posté par  (site web personnel, Mastodon) . Évalué à 2.

              Tellement (j'aimerais pertinenter plusieurs fois.) Mais pourquoi faire simple quand on peut faire bling-bling et pas passe-partout ?

              “It is seldom that liberty of any kind is lost all at once.” ― David Hume

            • [^] # Re: Jamais pratiqué

              Posté par  . Évalué à 2.

              C'est pour ça que je demandais s'ils utilisaient un moyen d'insérer ces caractères de manière vraiment simple.

              Imaginons avec un clavier comme le feu G15 de Logitech

              G15 Logitech

              Tu peux mapper chacune des touches G1 à G18 pour insérer le caractère qui va bien. Tu colle une étiquette sur chaque touche et je peux imaginer que ce soit pratique même avec grep (par contre pour awk il faut bien une version unicode…). Mais pour que toute l'équipe ai un setup vraiment pratique c'est plus compliqué (moi j'aime bien mais je sais que les claviers grands en mode tableau de bord ne sont plus à la mode). Perso pas pour ça directement, mais j'ai utilisé un pavé numérique séparé pour avoir une quinzaine de touches très spécifiques (des sortes de touches de fonctions personnalisées).

              Néanmoins, je vois un problème des emoji c'est que leur affichage dépend de la bibliothèque d'émoji ou de la font utilisée. Ce qui peut être jaune sur un outil peut être orange ailleurs voir pas du tout représenté pareil, la loutre de mon pseudo n'est pas pareil sous windows et linux par exemple.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: Jamais pratiqué

                Posté par  (site web personnel, Mastodon) . Évalué à 1.

                et je peux imaginer que ce soit pratique même avec grep (par contre pour awk il faut bien une version unicode…).

                AWK : l'un des pères fondateurs a corrigé le tir
                Attention que la gestion Unicode des bibliothèques GNU utilisées par certains outils (grep, tr, sed, cut, etc.) n’est pas topissime …mais ça avance

                Néanmoins, je vois un problème des emoji c'est que leur affichage dépend de la bibliothèque d'émoji ou de la font utilisée.

                C'est pour cela que je trouve le truc finalement compliqué, en supposant que ça s'affiche…
                Ajouter à cela que quand les lecteurs (…) passent sur ces caractères “dessins” (que tout le monde ne comprend déjà pas de la même façon), ça fait saigner les oreilles de l'accessibilité.

                “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: Jamais pratiqué

        Posté par  . Évalué à 5.

        Cette horreur est active sur le gitlab du taf.
        Du coup très régulièrement, je suis forcé de reprendre mes messages de Merge Request, un ':' ayant été remplacé par une interprétation oiseuse.

        Heureusement je n'ai pas ce genre de niaiseries dans mon terminal !

  • # Dans les tickets (scrum stories)...qui se retrouvent danz les commits.

    Posté par  (Mastodon) . Évalué à 3.

    Dans une des équipe où j'ai travaillé, on mettait les emojis dans les stories scrum, un sous ensemble plus restreint que gitmoji (fonctionnalité, bug, recherche, poc/ experimental, nettoyage, securité).

    Du coup ça se retrouvait dans le titre du ticket, qui devenait le nom d'une branche à laquelle tous les commentaires de commits d'une branche (parce que bon, ça n'a pas forcément d'intérêt que chaque commit ait un commentaire particulier) reprenaient le nom de la branche. Du coup oui tu retrouvait des emojis dans les commits.

  • # Des emojis partout SVP 🙂🙂🙂

    Posté par  (site web personnel) . Évalué à 5.

    J'adore gitmoji. Cela rend le git log bien plus facile à lire.

    Je l'utilise dans les titres d'issues et de PR, ainsi que dans les checklist sur ces dernières. Exemple :


    Title: :refactor: Simplify ansible playbook for nginx modsec policies

    Description:

    This PR provides the following changes:

    • [x] :truck: Rename template files for clarity
    • [x] :recycle: Render modsec rules with a Jinja2 template instead of perl scripts
    • [x] :fire: Remove obsolete Perl scripts
    • [x] :wrench: Add new hosts to the reverse-proxy hostgroup

    Mes PRs font ainsi office de "Architecture Decision Record", pratique pour l'onboarding. On s'attend à ce que le git log ressemble plus ou moins à la checklist, etc…

    De plus, le format :bug:, :sparkles:, etc… est toujours facilement greppable.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

    • [^] # Re: Des emojis partout SVP 🙂🙂🙂

      Posté par  . Évalué à 3.

      J'avoue, j'aime bien l'idée. J'ai cloné le repo de gitmoji pour voir l'historique dans gitk et c'est… pas très lisible :poop:.

  • # :art: c’est que pour un seul type d’art

    Posté par  (site web personnel) . Évalué à 3.

    J’ouvre la page du site « gitmoji », et la première entrée c’est:

    🎨 :art: Improve structure / format of the code.

    Et je constate qu’il y a encore des gens qui supposent que les outils et méthodologie de développeurs ne sont bons que pour les développeurs.

    Les artistes (dans le sens ceux qui produisent des images, du son, des modèles 3D, etc.) ont aussi le droit et le bénéfice d’utiliser un gestionnaire de version et donc d’utiliser et profiter des méthodologies d’étiquetage de commit.

    ce commentaire est sous licence cc by 4 et précédentes

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.