วีดีโอ

Hé oui... Avec la fermeture de l'activité il est difficile de trouver du temps pour produire 😥

Merci à toi 👍

Merci Jean-Marie pour ce joli témoignage 🙂

Merci à toi 😊

C'est normal, comme lors d'un merge ou d'un rebase classique, Git s'attend à ce que ton espace de travail soit exempt de modifications pour pouvoir appliquer les changements et gérer les éventuels conflits sans risque de perte de données (tes modifs en cours). Petite astuce dans ce genre de situation : git config --global rebase.autoStash true delicious-insights.com/fr/articles-et-tutos/git-stash/

@@DeliciousInsights Merci pour l’astuce 😍 Même si j’ai déjà eu des déboires avec des stash où la moitié des modifications disparaissent par magie…

Pas de disparition "magique". Probablement une mauvaise compréhension de ce que fait le stash et de comment ajouter/retirer @@Naej7

@@DeliciousInsights C’est à dire que quand je clique sur « stash » dans VS Code, que je pull, et que je clique sur « pop latest stash » pour me retrouver avec la moitié des modifications pendant que l’autre est disparue, ça fout les boules, et c’est probablement un problème côté VS Code..

C'est le problème de certaines interfaces graphiques qui, soit par défaut de l'interface, soit par une mauvaise configuration, produisent des comportements inattendus. Dans ton cas précis, il faudrait savoir quelle commande VS Code appelle. Si tu le fais à la main dans le terminal tu verras que le comportement ne sera pas le même (ou alors c'est que tu as foiré ta conf Git quelque part). Dans tous les cas, le mode autostash du pull te serait bien utile (sauf défaut du plugin VS Code).

Cette première valeur historique du réglage ne préserve pas tes merges locaux lorsqu'elle rebase ton histo local sur l'upstream à jour. Et pull.rebase = préserve, arrivé ensuite, avait quelques cas à la marge, elle est ajd dépréciée.

Peut-être que notre article détaillé sur le sujet t'éclairera plus : delicious-insights.com/fr/articles-et-tutos/bien-utiliser-git-merge-et-rebase/

Il s'agit de syntaxes de révisions différentes (voir "git help revisions"). Le "~" suivi d'un indice numérique N désigne le N-ième commit précédent le commit courant (en ligne droite). La notation "@{…}" correspond au reflog. L'indice numérique alors passé désigne la N-ième position précédente de la réf choisie. Par exemple, "main@{3}" désigne l'emplacement de "main" avant les 3 dernières opérations. On distingue la N-ième position précédente du N-ième commit en arrière car une branche peut subir des déplacements qui ne sont pas des création de commits (principalement "rebase", "reset"). On rentre ici dans des concepts avancés qui demandent plus qu'un short ou une explication courte en commentaire. J'espère avoir fourni un début de réponse utile.

@@DeliciousInsights Merci beaucoup, c’est très sympa de votre part de répondre 😉

Les gens qui bossent bien 😉

@@DeliciousInsights 1/ Est-ce l’historique git a tant d’importance que ça ? C’est du temps qui pourrait être passé à développer 🤔 2/ Si les gens bossent bien pourquoi est-ce qu’ils auraient besoin de modifier l’historique ? 3/ Git Flow est un enfer, vive le Trunk Based Development, où il y a plus vraiment besoin de merge et de rebase (donc de trifouiller l’historique) Mais je reste friand de vos arguments face aux miens, je ne doute pas un seul instant d’avoir plein de choses à apprendre 😉 (c’est bien pour ça que je suis abonné)

@@Naej7 Je suis tout à fait d'accord : si on bosse bien, pourquoi modifier notre historique ? La réalité est qu'on fait des erreurs. Pour ce qui est du "Pourquoi soigner son historique ?", j'ai presque envie de te retourner la question : "Pourquoi ne pas le soigner ?". Le soigner, c'est faciliter les fusions, les mises à jour (rebase), le report de correctif (patch, cherry-picking), les liens avec les outils tiers (par exemple l'automatisation de la fermeture des tickets dans GitHub, GitLab and co). Soigner son historique, c'est aussi progresser dans la qualité de la production pour finalement devoir le soigner / corriger de moins en moins car on s'améliore. Enfin, soigner son historique, c'est une forme de respect pour nos collègues avec qui on partage notre travail. Si je fais des commits fourre-tout, mal nommés, je pénalise probablement mes collègues s'ils doivent exploiter plus tard ces commits ou simplement s'ils veulent analyser efficacement l'historique. Pour Git Flow, c'est souvent un workflow inadapté aux projets, résultat d'une flemme managériale et cognitive des équipes qui n'ont pas souhaité analyser en profondeur leur besoin réel et qui ont préféré faire une recherche Google pour choisir la solution la mieux documentée ou qui propose de l'outillage intégré dans les éditeurs. À noter malgré tout que dans certaines situations il est fonctionne très bien. J'ai encore tout plein d'arguments, le débat n'est pas clos 😉. Du reste, on a une super formation dans laquelle on décrit tout le cheminement avec tous les arguments qui vont bien !

@@DeliciousInsights J’attends le jour où je me plaindrai de l’historique des commits des autres alors, ou inversement 😉 Je parle bien de l’historique, et pas des commits en eux-mêmes ! Je ne prends pas soin de l’historique tout simplement car le retour sur investissement est pas du tout intéressant 🤷‍♂️

@@Naej7 Je ne sais pas dans quel contexte tu développes tes projets (nombre de collaborateurs, durée, etc), mais je doute que sur le moyen/long terme le retour sur investissement ne soit pas intéressant. C'est comme la programmation : apprendre à utiliser les syntaxes modernes, concises, performantes est rarement un mauvais investissement. On espère avoir l'occasion un jour de débattre de tout cela de vive voix avec toi, par commentaires interposés ça n'est pas l'idéal.

Ça a demandé beaucoup de travail pour ne plus parler avec une patate dans la bouche 😉

Oui, supportedValuesOf n'a que peu de valeurs acceptées car les autres sont dérivables. Par exemple si tu n'as besoin QUE des noms de jour (pas pour afficher une date mais pour peupler une dropdown des jours de la semaine par exemple) tu peux toujours faire un Intl.DateTimeFormatter avec ton locale et l'option day: 'long' seulement, puis itérer sur 7 dates calées du lundi au dimanche et l'utiliser pour avoir le nom.

Pour les quelques valeurs autorisées par supportedValuesOf, regarde developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/Intl/supportedValuesOf#param%C3%A8tres

@@DeliciousInsights Tu gères, merci ! new Intl.DateTimeFormat(undefined, { weekday: "short" }).format(new Date())

Merci à toi ! Il est vrai qu'on est sur trop peu de radars, que ce soit notre chaîne, nos formations, nos workshops... Ce n'est pourtant pas faute de battre le rappel ! Comme toujours, les relais organiques et le bouche à oreille restent précieux et efficaces. N'hésite donc pas à parler de nous ! 😁

@@DeliciousInsights Ce sera avec plaisir. 😉

En fait c'est un tableau comme les autres en sortie de Object.entries(), on a donc sort() dessus. Lorsqu'on veut garantir un ordre défini c'est bien pratique !

@@DeliciousInsights Ce qui m'a surpris, c'est l'usage de sort sans argument. Est-ce que le tri se base sur la représentation en String des éléments ? Quand est-il des différents navigateurs qui (il me semble) ne trient pas toujours les clés dans le même ordre ?

Alors pour l'ordre de base (et non celui du tri, qui est le même partout) : - avant ES5, l'ordre d'énumeration des propriétés n'était pas défini. La plupart des navigateurs utilisaient l'ordre chronologique d'ajout à l'objet, ce qui est devenu la spec avec ES5. C'est l'ordre de for-in, Object.keys/values/entries/getOwnProperty*. Pour sort() sans arguments, les éléments sont alors toujours convertis en String, seule cible de conversion universelle. La conversion String d'un tableau c'est son join, ça commencera donc par sa première valeur, ce qui ici nous va très bien : c'est le nom de la clé. Coup de bol, en somme. Le tri reste lexicographique (ordre de la table Unicode) ce qui n'est pas fou si les clés sont en fait des textes naturels plutôt que des identifiants ASCII, auquel cas on devrait passer un comparateur maison utilisant localeCompare, mais sur des objets classiques c'est superflu.

Hello ! Je suppose que tu parles de la méthode .forEach, qu'on pourrait utiliser sur le tableau renvoyé par Object.entries() ? Le .forEach nécessite un callback et donc un appel de fonction à chaque tour, nettement plus coûteux qu'une boucle normale. Par ailleurs, il n'a pas d'équivalent au break / return au sein de la boucle. De façon plus générale, ce n'est dispo que sur quelques itérables prédéfinis, alors que for-of les consomme tous. Bref, for-of reste la meilleure façon d'itérer 😁

@@DeliciousInsights merci pour cette précision 😍

Ahah qu'est-ce qui t'y a amené ? Et ça t'a plu ? Tu as préféré quoi ?

Je ne te cache pas que je suis fan de cette astuce que je trouve beaucoup plus efficace et fluide quand il s'agit de reports réguliers. L'inconvénient est que ça pollue ton "log --all", mais on a toujours "log --branches" donc ça passe… 😉

Salut Jeremie. On a en effet rarement le contexte pour utiliser les patches. Personnellement, j'ai pris goût à ma "feinte" pour passer par le cherry-picking. C'est moins laborieux ! Pour le prompt, on utilise Oh My Posh, c'est une tuerie, ça marche avec quasiment tout les terminaux un tant soit peut graphiques : delicious-insights.com/fr/articles-et-tutos/git-oh-my-posh/ Si tu as besoin d'un peu plus d'info, n'hésite pas à demander 😉

Merci Vincent.

Merci Denis pour ton soutien. Si ce format marche, on en déclinera bien évidemment d'autres, tu t'en doutes bien 😉

Merci du compliment.

C'est ça l'idée 😉

Je ne te le fais pas dire ! C'est ça qu'on vise. Quiconque nous a déjà eus en formation sent le ROI :)

Hello ! Ça n'aiderait pas car c'est un dépôt imbriqué : il a son propre cycle de vie, ses propres ignores, etc

Salut Michel. Merci pour ton retour d'expérience. C'est vrai que dans ce genre de situation ça peut servir. Je me pose quand même la question de savoir si ça n'est pas plus contraignant à gérer et si ça n'est pas plus intéressant d'uniformiser ces pratiques. Es-tu le seul à faire des essais avec ce répertoire sandbox ?

Avec plaisir 😊

Et oui, "switch" est pourtant là depuis 2019. Je préfère clairement ce vocabulaire (tout comme celui choisi pour ses options). Ça aurait facilité mon apprentissage de Git à l'époque.

Merci pour ton témoignage 😁

C'est toujours un plaisir. Merci pour ton commentaire. Le switch est sorti en 2019 et vise à remplacer en partie le checkout pour offrir un vocabulaire plus clair et facile d'apprentissage (ses options sont également plus logiques). Perso, j'utilise encore "checkout" par réflexe 😅 (mon alias "co" pour être exact).

@@DeliciousInsights idem puisque j'utilise toujours le gitconfig de Christophe qu'il a publié dans un gist

Perso je me suis super bien fait au Switch, que je trouve en effet plus lisible et logique. J'utilise checkout uniquement pour des *checkouts* : amener des bouts de code dans le WD, pas changer de branche.

Je t'en prie. On est des fans inconditionnels du rebase. Ça demande un peu d'apprentissage, mais une fois qu'on a les bonnes habitudes, ça permet de gagner en qualité et en sérénité !

Merci pour ton retour. On vise exactement ça : fournir les infos nécessaires à la bonne maitrise du langage. Malheureusement, il est rarement bien enseigné ou appris, et trouver les bonnes infos s'avère parfois difficile. N'hésite pas à parler de notre chaîne et de nos formations autour de toi, notamment la ES Total pour maitriser 100% du langage 😉

Bonjour Jonathan, on utilise OhMyPosh et un thème qu'on a personnalisé. Tu as toutes les infos dans cet article : delicious-insights.com/fr/articles-et-tutos/git-oh-my-posh/ N'hésite pas si tu as d'autres questions.

Salut Antoine ! Et oui, c'est l'erreur classique qu'on fait et qu'on subit : utiliser les submodules là où on aurait mieux fait d'utiliser une alternative. C'est pour ça qu'on se donne du mal pour essayer d'expliquer tout ça 😉 et qu'on recommande au maximum les gestionnaires classiques de dépendances. Côté VSCode, malheureusement rien de spécifique au subtrees 🙁. Même GitLens, LA référence en terme d'extension Git, ne semble pas proposer d'aide au subtrees. Dans tous les cas, si tu utilises l'utilitaire subrepo ou une équivalence, tu sors d'une gestion "classique" des subtrees. Merci pour ton retour. Au plaisir de lire à nouveau tes commentaires 😁

@@antoinenauzet1568 Woah, YT a fait un truc chelou, c'est sûr ! Le lien de téléchargement remarche, on a calé les redirections vers le nouveau point de stockage sur notre CDN.

@@christopheporteneuvepro Super! Merci beaucoup! Je me demandais si ce n'était que chez moi. J'ai pu télécharger le zip! C'est top!

Merci à toi pour ton témoignage 🙂

Merci Vincent. Quelle efficacité ! À peine publiée, déjà regardée 🙂. En effet, on est plus ici sur ce qu'on pourrait qualifier de base élémentaire de Git.

Merci pour ton témoignage. On est heureux de savoir que notre travail est utile 🙂.

Avec plaisir 😊

Quokka.js (version Pro)

@@DeliciousInsights Merci

Il est super cool celui-ci hein ? 😊

Pas mal le prompt git log --graph --pretty=tformat:'%Cred%h%Creset -%C(auto)%d%Creset %s %Cgreen(%an %ar)%Creset'

Tu peux tout-à-fait les faire au niveau de ton compte...

@@DeliciousInsights Oui je me suis mal exprimé c'est bien au niveau du compte que je les fais en éditant le .bashrc. Par niveau du système, j'entendais "sur Linux au lieu de GIT".

@@uchitesting En effet, beaucoup de gens utilisent les aliases du terminal plutôt que ceux de Git, souvent parce qu'ils ne connaissent pas bien Git. Pour te faire un retour d'expérience personnelle, je préfères largement les aliases Git car ça centralise avec la techno. On profite aussi de la complétion sur les options (et les aliases d'ailleurs).

Ravis que ça t'ait débloqué !

Merci à toi 😊

Quokka.js, en édition Pro.