L'un des piliers DevOps est l'automatisation.
Or, il n'y a pas d'automatisation sans code, et Git est devenue essentielle dans la collaboration
autour du code source. Pour moi, c'est même la colonne vertébrale du cycle de vie d'une
application DevOps. C'est aussi un outil de communication au sein de l'équipe, y compris
entre les devs et les ops. Pourtant, on constate qu'il est rarement pris au sérieux dans l'enseignement,
nous en parlions justement dans Radio DevOps n°19 sur les filières courtes, je vous mets
le lien en description. Mais les ingénieurs ne sont pas mieux lotis.
Bienvenue sur Radio DevOps, la balade aux diffusions des compagnons du DevOps. Si c'est la première
fois que tu nous écoutes, abonne-toi pour ne pas rater les futurs épisodes. C'est parti !
Bienvenue à toi chers compagnons, alors dans cet épisode, on est là pour t'aider à débuter
avec Geet. Je vous en parlais en introduction, mais que l'on soit ingénieur au convient
de filières courtes, j'ai constaté en tout cas avec mes stagiaires et alternants que Geet
n'était pas forcément bien compris, bien pris au sérieux ou même bien pratique.
Donc dans cet épisode, on va partager nos tips et nos bonnes pratiques et on va faire
des retours d'expérience autour de Geet, cet outil vraiment essentiel.
Et avec moi aujourd'hui, j'ai pour en parler Erwan. Bonjour Erwan. Bonsoir. Et René. Bonjour René.
Bonjour. Alors je précise, petit disclaimer avant qu'on commence, que ce podcast n'est pas là
pour remplacer une formation. Si vous vous attendez à être formé sur Geet à la suite de ce podcast,
bon, je pense que vous avez de très hautes espérances, mais c'est pas là pour ça.
Nous, on va vous faire un retour pratique de nos avis. On va vous partager des bonnes pratiques,
mais ça ne remplacera jamais une formation. Donc, formez-vous à Geet. Vous avez des tutos très
bien, mais si vous voulez aller plus loin, vous pourrez trouver des formations sans aucun problème.
Si jamais vous intéressez très fortement à Geet et si cet épisode vous plaît,
j'ai créé une communauté qui est dédiée exclusivement à Geet et Geet Lab. Donc c'est la communauté
frogeet. Et donc, en t'inscrivant, tu recevras en plus mon antisèche Geet. Tu retrouveras en
plus sur le wiki lié à la communauté un guide des bonnes pratiques que j'ai écrit. Pour t'inscrire,
c'est le premier lien en description. C'est hyper simple. Alors, on va commencer par parler de
qu'est-ce que ce que Geet, c'est quoi ce truc ? Ça sert. Est-ce qu'on peut avoir une petite
définition de Geet et c'est René qui s'y colle pour commencer ? Alors, tu prenais risque. Donc Geet,
c'est un SM, source code management, si je dis pas de bêtises. En bref, pour faire simple,
c'est un outil qui permet de pallier à nos déficitions humaines, notamment notre mémoire,
et qui va permettre de suivre les versions et les évolutions, les modifications qu'on fait sur
un ensemble de fichiers. Voilà, je pense que c'est la déficitions la plus courte que je peux donner
si vous voulez rencheirir. Oui, c'est ça. C'est que ça permet de répondre à la question du qui,
quand et quoi sur du code. Alors, moi, je peux aussi vous donner un petit point de vue. De mon
point de vue, ça permet d'éviter de séparer vos fichiers dans des dossiers comme on le voit
régulièrement, ou de les renommer vers version 1, version 2, version 4, version 5. Geet,
c'est un outil magique si vous adorez les univers parallèles et si vous avez toujours rêvé de remonter
dans le temps. Je vous fais rêver, mais c'est vraiment ça. Pour moi, c'est clairement ça.
C'est quand on utilise Geet, on a des univers parallèles, les branches, mais on va en parler,
et on peut remonter dans le temps, on peut remonter dans l'historique. Du coup, j'aimerais qu'on
parle un petit peu de notre rencontre avec Geet, comment elle s'est passée, dans quelle condition,
est-ce qu'on s'en rappelle encore ? Et R1, est-ce que tu peux commencer sur...
ta rencontre avec Geet nous raconte un petit peu ta petite histoire derrière ?
Oui, oui. Alors, juste les SCM, il y en a eu avant Geet. Moi, j'ai commencé à utiliser ce
genre d'outil avec SVM, qui est donc aujourd'hui un peu désué, mais qui était le l'outil
dominant à l'époque. Et en fait, je pense que j'ai commencé à me mettre à Geet, ça devait être
en 2009. Et c'est quand j'ai rejoint une boîte où en fait, j'avais pas le choix,
il faisait du Geet. Moi, je venais de SVM, alors je peux vous dire que le choc a été un petit peu
frontal au début, mais c'est comme ça. En fait, j'étais dans une boîte qui utilisait Geet.
Mon premier projet, c'était justement de mettre une espèce de couche avec des gestions de droits,
etc., qui s'appelle... Alors, je ne sais pas si ça existe encore comme projet, mais Geetolight,
qui est une espèce de surcouche à Geet pour gérer tout ça. Et donc, c'est comme ça que j'ai connu Geet.
Mais sinon, la gestion de code, je connaissais ça avant avec du coup SVM. Et toi, René ?
Alors moi, là, on va remonter autant des dinosaures. Je fais une petite référence au mot de la fin
d'une précédente émission qu'on a faite. Moi, j'ai commencé avec RCS, parce que j'ai assez
vite vu l'avantage de suivre les fichiers, mais RCS, c'était même pas en réseau,
c'était le mythe perso après CVS. Puis subversion, et puis Geet, et Geet, une assez grosse révolution.
Par contre, je l'ai utilisé quand même pas mal de temps en mode un petit peu, je ne sais pas dire
superficiel, mais voilà, je me sens allé trop trop dedans. Et par contre, à un moment où je me suis
lancé à faire un projet un petit peu annexe dans la communauté OpenStack, un ProFoF Concept.
Et là, j'ai dû vraiment aller plus loin et découvrir bien plus en profondeur.
Voilà, c'est mon expérience avec Geet. Et puis depuis, je l'ai mis en place,
enfin, j'ai aidé certaines équipes chez des clients à essayer de mieux appréhender ça plusieurs fois.
Alors moi, j'ai commencé aussi avec CSV. Avec Tortoise CSV, je m'en rappelle,
j'étais chez Casino. C'était compliqué. J'étais l'un des rares dans l'équipe d'exploit.
Pour info, dans l'équipe d'exploitation, on installait les applications. Et moi,
je fais beaucoup de scripts, de déploiements d'applications. C'est moi qui était un peu chargé
de ça puisque j'avais un passive de développeur. Et puis voilà, je me débois il y a pas mal en
Chef Script. Et très vite, j'ai eu des soucis en fait à gérer les versions, etc. Et j'ai su que
dans la boîte, il y avait un gestion de version. Donc, j'ai demandé des accès aux gestions de
version qui n'étaient que par les développeurs. Donc, je devais être l'un des premiers apps
à utiliser ça. Et c'était une purge parce que ce n'est pas mauvais, mais c'était pas pratique.
Et du coup, je suis passé à Git plus tard. J'ai découvert Git entraînant avec des développeurs
web à l'époque. Et je viens de retrouver en fait ma première activité sur GitOps. Ça date de
décembre 2012. Mais c'était juste mon inscription. En fait, mon premier commit date janvier 2014.
J'ai commencé vraiment, je pense, à utiliser Git en local dans cette année-là, en fait 2013-2014,
et à commencer à vraiment utiliser ça de manière régulière à ce moment-là. Et puis,
quand je suis devenu freelance, là, je suis rentré avec une équipe de développeurs qui n'utilisaient
que Git. Donc, il a fallu que je m'y fasse. Et j'ai appris Git à la dur avec eux parce que c'était
pas facile. Parce que c'est là où j'ai appris à être tatillon sur les messages de comites,
etc. Parce que je faisais comme tout le monde fait, modifier une nuit, à de machin. Bref, je vous
passe. On en parlera plus tard peut-être. Voilà, ma rencontre avec Git. Alors, maintenant qu'on a un
peu expliqué ce que c'était Git, on va peut-être dire d'où ça vient. Et Erwan, je crois que tu
veux nous dire quelques petites choses à ce propos. Oui, du coup, d'où ça vient, c'est créé par
Linus Torvald. Ça a été créé en 2005. Le pourquoi ça a été créé, c'était que, enfin,
Long Story Short, c'est que Linus Torvald a trouvé que les outils, justement, comme S-Ven,
donc, une version, étaient un peu dépassés parce qu'ils n'étaient pas décentralisés. C'était
très compliqué de travailler à plusieurs sur un même projet. Et donc, en fait, de ce besoin-là,
et né Git. Alors, j'ai dit décentralisé, mais il y a aussi le côté de Asyncre, puisque chacun
sa propre copie du code, etc. Et qu'on pousse quand on veut sur une branche de référence. Et donc,
c'est né de ce besoin-là. Et en plus, il y avait cette volonté de rendre les, je ne sais pas si vous
avez déjà cloné des repos S-Ven qui ont beaucoup d'Historix, excessivement longs. Et en fait,
le Git, justement, devait embarquer une des features qui a fait émerger Git. C'était aussi
le fait que quand on récupère du code ou quand on en pousse, en fait, tout est compressé. Et donc,
du coup, on pousse et on récupère que des diffs. Et c'est des diffs qui sont compressés. Donc,
forcément, on gagne en performance. Donc, c'est de là qu'est né, enfin, c'est à partir de tous
ces besoins et ces frustrations, ces frictions qu'est né Git. Et il y a une petite vidéo,
je suis juste finir là-dessus, il y a une petite vidéo qui est un talk de Linus Torvalde qui
tient chez Google pour justement raconter un petit peu toute la jeunesse du projet. Et la
vidéo est assez connue puisque la personnalité très particulière de Linus Torvalde est assez
éblouissante dedans. Voilà. Justement, en fait, il y avait aussi une autre raison, c'est qu'ils
utilisaient pour la gestion des sources de Linux, ils utilisaient BitTipper, donc qui était un
gestionnaire, un SCM propriétaire. Et donc, c'est une histoire de logicielie, bon à quelque part,
parce que, en fait, ce code propriétaire, Linus, lui, ça lui convenait, mais il y a eu un certain
nombre de choses qui se sont passées qui ont fait que l'éditeur du logiciel ne voulait plus te donner
de licence gratuite au développeur du kernel, entre autres parce qu'il y a eu des rivers engineering,
du code, etc. Allez voir une vidéo, il y a certaines vidéos qui vont mentionner ça. Et voilà,
du coup, comme il ne pouvait plus avoir de licence gratuite, Linus, c'est un peu déchaîné, il a fait
un outil pour remplacer BitTipper. Et il déteste l'NVN, du coup, ce que tu as dit est complètement
vrai, il ne voulait pas du tout remplacer par NVN. Justement, tu parles de vidéo, je vous renvoie
à la vidéo de CoqAdmin qui nous parle du conflit qui crée à Git, je mets le lien en description
si vous voulez en apprendre plus sur la genèse et la création de Git. Mais du coup, pourquoi est-ce
que c'est si important Git ? Parce que, outre le fait de gérer nos versions, Git a une place encore
plus importante pour moi que les autres gestions de version, pour plein de raisons. Alors déjà,
je peux vous citer le fait que Git, c'est un outil de communication entre les équipes, parce que si on
se concentre juste sur Git, vous pouvez communiquer avec votre équipe, avec les messages de comites,
et donc dire pourquoi vous faites les choses et pas juste comment vous les faites. Et si on
extrapole avec les outils tels que GitHub, GitLab ou Frogit, vous pouvez aussi communiquer autour de
votre dépôt avec les issues, avec les merges réquestes. Et donc tous ces trucs-là font pour
moi que Git est vraiment important pour communiquer entre les membres de l'équipe.
Je vous ai séché là. C'est d'accord ? Bon ben, nickel. Bon alors du coup,
l'autre truc qui pour moi est vraiment intéressant, c'est finalement Git, ça a plein d'événements,
notamment quand on crée un comité, qu'on le pousse sur le dépôt. Donc Git, c'est décentralisé,
comme tu l'as dit, ça veut dire qu'on a notre dépôt local sur nos machines et on a un dépôt
central qui permet à chacun de venir récupérer le dépôt de code ou pousser pour mettre à
disposition les évolutions qu'on a fait. Et du coup, ce dépôt central, il peut servir pour écouter les
événements Git, donc les poules, les merges, si on merge une branche dans une autre, la création
des tags, enfin il y a plein d'événements dans Git et on peut faire pas mal de choses avec ces
événements en le couplant avec une intégration continue et un déploiement continue. Et ça pour
moi, c'est une des forces de Git et c'est ce qui fait qu'aujourd'hui, Git est si centrale dans le
DevOps parce que vraiment sans Git, en fait, on pourrait pas faire pas mal de choses qu'on fait
aujourd'hui dans le DevOps. Je sais pas si vous êtes d'accord avec ça. Alors oui, mais c'est pas propre
à Git, ce que tu décris, puisque moi je me souviens que ce qu'on avait sur Asven, on avait aussi
des événements qui trigger l'équivalent de la CIA qu'on avait à l'époque par exemple. Mais ce qui est
vrai, c'est qu'il y avait le côté décentralisé qui est important, le côté aussi à Synchron,
c'est-à-dire que sur Asven, sauf si mes souvenirs sont erronés, mais tu peux pas travailler avec Asven
sans avoir d'accès à ton repo central. Alors que Git, même si tu n'as pas de Wifi ou quoi que ce soit,
tu fais toutes tes modifications en local, même si tu es dans le train ou quoi que ce soit et
puis dès que tu récupères une connexion, tu peux poucher. Et moi, c'est plus là-dessus que pour moi,
ça a changé le paradigme parce que avant, tu étais contraint par ton SM et avec Git,
et puis il y a d'autres... on l'a pas cité, mais il y a d'autres outils qui sont aussi décentralisés
à Synchron, etc., comme Mercurial. Et Git a vraiment changé, en tout cas pour moi, le truc là-dessus.
Et pour moi, c'est ça qui fait que c'est devenu beaucoup plus important que Asven, qui finalement,
quand tu comparles les deux, en fait, tu vois que des contraintes à Asven. Enfin, je vois pas des
gens qui ayant connu la souplesse de Git vont se dire en fait, c'était pas si mal Asven. Au-delà
d'autres avantages qu'on n'a pas encore cités qui sont la résolution de conflit, des merges, etc.,
mais donc voilà. Ce que je voulais juste dire, c'était que du coup, les événements que tu décris,
c'est vrai qu'avec Git et puis surtout les intégrations qu'il y a avec GitLab, Git Hub,
etc., font qu'il y a énormément d'événements que tu peux récupérer effectivement pour alimenter
ta CIA et tout. Mais en vrai, tu pouvais retrouver déjà ça avec les outils un peu plus vieux.
J'ai pas connu ça. Alors, on parle d'intégration continue. Moi, je vous renvoie à l'épisode
numéro 11 qu'on a fait sur l'intégration continue. Il y a le lien en description. Vous
pourrez prolonger l'intégration continue. Erwan, tu voulais nous parler aussi du fait que Git était
pas mal réservé au Dev. Oui. Je voulais dire que je pense aussi que l'usage des SM de façon
générale, en tout cas, moi, quand j'ai commencé ma carrière, ça a remonté un petit peu,
mais en gros, les SVN au début, on voyait vraiment ça pour le code des Dev. Et en fait,
aujourd'hui, surtout avec l'émergence de mouvements DevOps, etc., en fait,
on se rend compte que ce besoin de versionner ce qu'on fait peut s'appliquer à n'importe quoi.
Donc, effectivement, le code, ça a du sens. Mais aussi vos docs, vos configs. Moi,
j'ai même personnellement mes recettes qui sont versionnées sur GitHub. En fait,
c'est juste ce besoin de pouvoir itérer sur quelque chose et de pouvoir le tracer. Et
le tracer avec les messages que tu évoquais un peu plus tôt. Et donc, du coup, ça a souvent
été, on va dire, plus du côté Dev. Et en fait, avec le mouvement DevOps et tout,
je pense qu'aujourd'hui, dans les bonnes pratiques, dans les premiers points, il y a
forcément ce besoin de versionner tout ce qu'on fait, que ce soit le code, la doc, les configs. Et
ça, je clairement guide, donc encore une fois, avec tous les avantages certains qu'on a cités
et tout, a vachement renforcé ce point-là, en tout cas, de mon point de vue. Je ne sais pas si
vous êtes d'accord. Oui, absolument. Je pense qu'il faut sortir absolument de la tête des gens.
Ce que disait Christophe, gérer ses versions de fichiers en créant des nouveaux fichiers v1,
v2, v3, c'est plutôt une très mauvaise pratique et que vraiment un gestionnaire de version,
c'est absolument indispensable aujourd'hui pour suivre un petit peu ce qui se passe. Et même
avec ce type d'outil parfois, ça peut être compliqué. Donc sans, c'est juste un cauchemar.
Oui, c'est vrai. J'ai vu des stagiaires me faire ça justement. C'est pour ça que je le disais,
mais du coup, ce n'est pas de la blague. Il y a vraiment des stagiaires qui arrivaient,
qui commencent à me faire des répertoires. Je leur demandais pourquoi ils me faisaient ça,
alors qu'on avait un dépôt-guit et tout. En fait, ils voulaient cloner le dépôt-guit dans
plein de répertoires. Je leur expliquais maintenant, tu n'as pas besoin avec les branches. On en reviendra.
Et justement, René, tu voulais parler de contribution ?
Oui, après, c'est un petit point que je voulais rajouter. C'est que un guide,
en fait, c'est la base à d'autres services en ligne. On a évoqué GitLab, GitHub. Et pourquoi
il faut le connaître ? C'est que pour utiliser GitLab, GitHub, avoir une compréhension de
Git, ça va énormément faciliter les choses et l'utilisation de ces services-là. Et aussi,
c'est aujourd'hui, si les gens sont intéressés pour faire des contributions sur du logiciel libre,
voilà, à travers ces outils-là. Mais, tu réponds quoi aux gens qui disent que,
justement, Git, ça ne marche pas ?
Oui, il y a des gens qui m'expliquent ça des fois. Git, ça ne marche pas. C'est des équipes de 10,
ils ne s'en sortent pas et tout ça. En fait, souvent, c'est un problème de connaissance
de l'outil parce que c'est un outil qui, malheureusement, on croit que c'est extrêmement
facile, etc. Mais c'est un outil extrêmement puissant. Donc, il faut effectivement apprendre
à le maîtriser. Et souvent, je réponds que ça marche quand même pour des projets de taille plus
conséquentes avec des milliers de développeurs. Donc, je pense qu'une équipe de 10, si on fait
l'effort de se former et de l'apprendre comme il faut, il n'y a aucune raison que ça marche pas.
Ça, c'est vrai. Il n'y a pas de raison que ça ne marche pas.
Erwan, tu veux rajouter quelque chose sur l'importance de Git ?
Non, mais je rejoins tout ce que René vient de dire. Aujourd'hui, c'est un outil, en tout cas, dans le
monde open source. C'est un outil indispensable dans les gros projets. Bien sûr, on n'est pas
forcément obligé d'être contributeur sur ces trucs-là. Mais par exemple, carnel Linux,
debian, GNOME, Android, tout ça, c'est sur Git. Et même, les projets historiques qui étaient
sur S-Ven, en fait, ils ont bougé sur Git aussi pour faciliter la contribution. Donc,
aujourd'hui, si on veut participer à un projet open source, connaître Git, c'est indispensable.
Exactement. Du coup, une fois qu'on a compris pourquoi c'était important, on a quelques
petites bases à connaître, on va appuyer un petit peu sur ces bases-là. Et justement,
tu nous disais, Erwan, que c'était décentralisé. Est-ce que René, tu veux justement rebondir sur
ça ? Oui, en fait, c'est une redis de ce que Erwan a dit. Ce qu'il faut bien comprendre, c'est
qu'autant SVN, c'est un modèle client-server et ce que disait Erwan, on ne peut pas, si on n'est pas
connecté au serveur, on ne peut pas faire grand chose. Là, Git, ce qu'il faut bien comprendre,
c'est qu'on est complètement, on a le système en entier sur sa machine. Donc, on peut travailler,
on peut travailler de manière autonome dans le train, comme ce qui a été mentionné. Et voilà,
ça va nous permettre de vraiment nous resynchroniser quand on le souhaite et quand on va avoir la
connexion disponible par rapport aux ripositories, entre guillemets, distants, centrales,
potentiellement. Et ça a un autre aspect intéressant, ça, mais je parlerai un peu plus tard.
Erwan, est-ce que tu peux nous parler juste selon toi, quelles sont les concepts essentielles à
connaître ? Ah oui, parce que Git, si vous voulez vous faire mal à la tête, il faut regarder le man.
Il est quand même très costaud et puis il y a 12 milliards de sous-commandes, etc. avec des
options qui sont parfois hyper triquées à utiliser. Mais en fait, sans aller jusque-là,
en fait, il y a, comment dirais-je, dans les bases à connaître, finalement, il n'y a pas grand chose.
Et en fait, c'est des choses qu'on retrouve aussi dans d'autres concepts, enfin dans d'autres SM,
c'est des concepts assez classiques. La notion de comites, la notion de branches. Donc, le comites,
c'est en gros l'incrément de codes de modifications que vous avez fait. La notion de branches,
c'est justement le fameux monde parallèle qui évoquait à Christophe. C'est-à-dire qu'au lieu de
modifier, d'essayer de modifier quelque chose de commun, vous travaillez sur un environnement qui
est issu de cette source et vous allez faire vos modifs et puis ça va vivre donc du
coup dans deux branches possibles, enfin différentes. Donc, connaître cette notion d'univers parallèle,
c'est quand même hyper important. Dès que vous utilisez des outils comme GitLab,
GitHub, la notion de pool request ou de merge request, elle est indispensable aussi à connaître
et à comprendre parce que c'est ça qui va vous permettre de travailler en équipe. Donc,
concrètement, une pool request ou une merge request, c'est justement ce côté. J'ai travaillé
sur mon univers parallèle. Maintenant, j'aimerais bien que mes modifications de mon
projet, et donc du coup, ça fait, on crée donc une pool ou une merge request, les tags qui sont
en fait finalement des marques pages qui permettent d'identifier facilement un comit dans l'histoire
de votre repository. Et après, il y a encore plein de choses, mais déjà rien que connaître ça et
être à l'aise avec ces notions-là, ça va vous permettre déjà de faire pas mal de choses. Et
en fait, la suite, je pense qu'on l'apprend assez vite quand on est confronté à devoir faire des
choses sur Git et c'est là que Stack Overflow va vous sauver parce que si vous avez une question
sur Git, c'est sûr que vous allez trouver quelqu'un sur Stack Overflow qui a eu le même problème et
vous allez toujours trouver une réponse avec des fois des one-liners un petit peu bizarre,
mais qui font ce que vous allez rechercher. Est-ce que vous êtes d'accord sur les notions de base à
connaître ? Oui, je vais juste rajouter un petit chose, c'est qu'une des misères de SVN, c'était
justement la gestion des branches. C'était faisable, mais c'était toujours un petit peu
tricky, on va dire. C'est le gros plus de Git, c'est qu'une branche ça coûtera un,
il ne faut pas, moi, souvent, quand personne aujourd'hui n'hésiter pas à faire des branches,
ça permet de sauvegarder un état, ça permet de faire des essais, de faire plein de choses,
et ça, entre guillemets, aucun coup, c'est un pointeur quelque part. C'est de faciliter
à pouvoir créer des branches et c'est vraiment un gros point fort de Git. C'est vrai qu'on l'a pas
dit, mais il y a aussi un truc dans Git dont on n'a pas parlé, c'est vraiment la performance qu'il
a, notamment pour créer les branches et les égérer toutes les versions parce que SVN,
c'était assez long, je me rappelle, alors que Git, c'est ultra rapide, tu crées une branche,
pouf taille, ta branche. Donc ça, c'est vraiment impressionnant. Erwin, tu voulais rajouter un
petit truc sur un, tu voulais faire un petit auto promo pour quelque chose ? Mais oui, bien sûr.
Il y a, en fait, j'anime décours à côté de mon taf et il y a un décours qui est une
introduction à Git justement avec pourquoi c'est bien, pourquoi, enfin, les quelques bonnes
pratiques, d'où ça vient, etc., avec un petit exercice très très simple, mais juste pour
se forcer à utiliser l'outil et à faire des choses. Et donc, j'imagine qu'on mettra le lien
quelque part sur le site, mais donc du coup, voilà, c'est pas très long, c'est pas prétentieux et si
ça peut vous aider, si vous n'êtes pas à l'aise, c'est toujours ça de prix.
Oui, on mettra le lien en description. J'en profite pour te dire qu'il n'y a pas de licence associée
à ton document. Ah, faites-en ce que vous voulez. C'est What the Fuck licence.
Ce serait bien de l'adiquer la What the Fuck licence.
Je vais rajouter ça.
Tout à l'heure, merci. Tout à l'heure, on a parlé de remote, de branches, remote ou
branches locales. Rene, tu voulais nous parler d'un petit truc, justement, à propos de ça,
du remote update, je crois ? Oui, c'est un petit tips en fait, ce qui est effectivement, on peut
comment dire ? C'est une des forces de guide aussi, c'est qu'on peut cloner un projet,
enfin voilà, il y a une vraie volonté un petit peu philosophique de pouvoir prendre un projet
de le forquer, entre guillemets, cloner, forquer pour en faire ce qu'on a envie. Il n'y a pas de
limitation à ce niveau-là, globalement. Et du coup, on peut se retrouver parfois à voir plusieurs
remotes parce qu'on n'est pas obligés d'avoir qu'un seul remote, donc un repository central
identifié, voilà, pour en avoir plusieurs. Notamment, on a souvent ce cas sur GitHub, on peut
avoir son propre projet, enfin, on peut avoir un projet qu'on est souvent, on va le nommer upstream,
qui est le projet avec le repository souvent en référence, et souvent ce qu'on fait,
c'est qu'on fait un forc de ce projet-là, et on va avoir donc notre propre copie sur
GitHub de ce projet-là. Et donc, on peut avoir deux remotes, un remote upstream et un remote qui va
souvent s'appeler origin par convention. Et voilà, donc après, il y a une commande qui s'appelle
guide remote update qui permet de mettre à jour l'enfin, d'aller se synchroniser, de récupérer les
données des distants, donc de tous les remotes d'un seul coup. Voilà, plutôt que de faire guide
fetch, origine, guide fetch upstream, voilà, il y a un truc qui permet de le faire d'un coup, voilà,
après, il y a des raccourcis dans guide, guide fetch, guide fetch, moi-même, voilà.
On a dit qu'on essayait pas de le commander. Je vais éviter.
Ouais, il y a plein de commandes dans mon montissage, donc aller télécharger mon montissage,
vous aurez plein de commandes de celles que j'utilise au quotidien.
Voilà, ce qu'il faut vraiment garder à l'esprit, c'est qu'on peut avoir plusieurs remotes.
C'est vraiment ça qui est important. Ouais, ça, c'est vraiment vrai quand tu participes à un projet
libre ou tu veux contribuer, du coup, tu clones le projet, tu fais tes modifs sur ton projet,
mais parfois, tu as besoin de récupérer le projet d'origine pour mettre à jour ta copie locale.
C'est dans ce genre de cas que tu fais ça, l'esprit.
Oui, oui, souvent, c'est ce qu'il y a là, très souvent.
Bon, alors moi, je vais vous parler des commits parce que les commits, c'est un vrai sujet.
Quand vous faites des messages de commit, il faut que je fasse ça, il faut que je fasse ça.
Quand tu fais des messages de commit, si tu es novice, tu as souvent tendance à décrire ce que tu fais.
C'est-à-dire si tu modifies ton remis, souvent, en tout cas, je l'ai constaté très régulièrement,
les novices de Git et je les fais, je pense que R1 et René l'ont fait aussi,
ont décrit ce qu'on fait, c'est-à-dire je modifie le remis, j'ajoute telle section
au remis, etc. Sauf qu'en fait, quand on fait ça, on fait de la paraphrase parce que Git nous dit déjà ça.
Alors en fait, quand on regarde l'historique et dans un commit, on a plein d'informations,
y compris quel fichier on a modifié, qu'est-ce qu'on a modifié comme ligne, etc.
Donc ça ne sert à rien de dire ce que Git nous donne déjà comme information.
Par contre, ce que Git nous donne pas comme information, c'est pourquoi est-ce qu'on fait les modifs.
C'est quoi la raison profonde de cette modification ? Je prends l'exemple du rédemi.
Je vais modifier un rédemi pour ajouter une licence.
Donc l'information importante, c'est pas modifier le rédemi pour ajouter à licence,
c'est mise en place de la licence, gpLv3 par exemple.
Ça, c'est une information importante plus que j'ai modifié le rédemi.
Et donc pour éviter de vous casser la tête à écrire des messages de commit,
si vous voulez utiliser une convention, parce qu'on aime bien les conventions dans l'informatique,
il y a ce qu'on appelle les commits conventionnels ou les conventionnels commits.
Je vous mets les liens en description.
C'est une convention de nommage des commits qui va vous faciliter la vie.
Et au bout d'un moment, quand vous l'aurez pris en habitude,
vous vous poserez même plus la question de qu'est-ce que je vais mettre dans mon message de commit,
parce qu'il y aura peut-être plein de petites infos cumulées dans cette convention
qui vont vous aider à créer des messages de commit pertinents et surtout à ses cours.
Je peux ajouter deux petites choses.
Ce que tu dis là par rapport à la description des commits, etc.
C'est aussi vrai pour les commentaires de code.
En fait, ce qu'il faut essayer de se dire, c'est de transmettre l'intention.
De ce qu'on veut faire.
Et voilà, il faut essayer de garder ça en tête pour faire un bon message de commit.
Et l'autre point, c'est que conventionnels commits,
il y a aussi un certain nombre d'outils qui, si on respecte la convention justement,
vont pouvoir s'appuyer là-dessus pour faire,
exemple, faire un change log automatique ou des choses comme ça.
Donc ça, c'est un peu ce double avantage.
Exactement.
Et j'en parlerai plus tard sur la chaîne YouTube.
J'ai prévu de faire quelques quelques vidéos là-dessus sur les change log automatique.
L'intégration des change logs dans les rédits, etc.
Vous verrez, ça va arriver.
Baronet, écoute, tu as encore plein d'infos à nous passer dans les bases à connaître.
Tu voulais parler du contexte local ?
Oui.
Alors, c'est...
Alors, on va dire qu'on a mis ça dans les bases,
mais c'est peut-être aussi potentiellement un piège.
T'alors, je disais effectivement, c'est décentralisé.
On a l'ensemble du système, entre guillemets, sur sa machine.
Ce qu'il faut comprendre, c'est que quand on fait un guide diff,
pour comparer ce qu'on a,
entre ce qu'on est en train de faire et le remote,
il faut bien comprendre que ce qu'on compare,
c'est son local et une copie de la branche remote.
C'est-à-dire, à un moment, la dernière fois qu'on s'est synchronisé,
on a ramené une copie du remote.
Et notre comparaison va se faire entre notre branche locale
et la branche remote, qui est une copie de ce qu'il y avait.
Ce qui veut dire que si on s'est pas resynchronisé entre temps,
une des confusions, c'est parfois on se dit,
je suis en train de faire une différence entre mon local et mon distant,
mais non, pas forcément.
Si ça n'a pas été remis en resynchronisé entre temps,
on est juste en train de se synchroniser sur une version
qui n'est peut-être plus à jour.
Donc ça, c'est un piège.
C'est aussi pour renforcer cette notion de distribuer.
Des bonnes pratiques, je dirais,
c'est de se synchroniser assez régulièrement
pour être sûr que quand on fait une copie,
on est une version suffisamment à jour.
Et tu voulais nous parler aussi de la réécriture de l'historique.
Pour moi, ça, c'est aussi une énorme force de guide.
En fait, c'est cette possibilité de réécrire l'historique
et de supprimer, par exemple, des comites.
Mais donc une des bonnes pratiques,
c'est quand même de comiter assez régulièrement.
Et voilà, mais parfois, on peut se rendre compte
que sur les 15 comites qu'on a fait,
il y en a entre guillemets trois qui sont pertinents,
dans le sens en termes de description.
Parfois, on peut aussi comiter pour sauvegarder un état.
Et du coup, en fait, ça rend l'historique assez difficile à lire.
Et donc avec guide, il y a la possibilité de remodifier cet historique
en fusionnant des comites.
Parfois, on en supprime,
parce que parfois, ils peuvent ne pas avoir de sens,
ou en ajoutant, parfois aussi, on peut aussi en ajouter.
Bref, on peut vraiment raffiner notre historique
et rendre quelque chose d'assez propre.
Et un exemple, c'est enlever des comites qui disent,
« Tiens, j'ai changé une typo. »
Voilà, ce n'est peut-être pas un comite très pertinent.
Parfois, on peut vraiment affiner tout ça.
Oui, quand on fait du développement,
que ce qu'on soit obssudev,
à un moment donné,
avant de soumettre notre merge request ou notre pool request,
on va tout relire, on va essayer de réorganiser ça.
Ça fait partie du refactoring.
On peut refactoriser aussi l'historique de comites.
Ça me permet d'embrayer tout de suite sur la section suivante.
Oui, je voulais juste rajouter un petit truc.
Après ça, ça est aussi très dépendant des projets, en fait.
Dans le monde de l'open source,
par exemple, il y a des projets qui vont demander
à ce qu'une modification, ce soit un comite.
Faire squasher ce qu'on dit souvent, squasher les comites.
Donc ça, c'est des règles.
Il y a des règles à définir, entre guillemets, dans l'équipe,
sur ce que tu disais, le conventionnel comite,
sur l'écriture des comites,
mais aussi des règles sur la manière dont on va amener les modifications.
Je pense qu'on va revenir dessus dans la section équipe.
On va parler des pièges à éviter.
Et justement, vu qu'on parle directement de la récriture de l'historique,
il y a un truc à bien comprendre,
c'est que chaque comite est unitaire,
mais chaque comite a une histoire.
Et donc, dans son histoire, chaque comite, il connaît un parent.
Et si on réécrit l'historique, forcément, le parent, il change.
Je m'explique.
Si on a trois comites et qu'on fusionne les deux comites du milieu,
le dernier comite, il a perdu son papa ou sa maman,
et du coup, il change.
Parce que, du coup, l'ID du comite va changer.
Ça, c'est important à l'avoir en tête.
Quand on fait une récriture d'historique, le comite va changer.
Et du coup, ce sera plus le même.
C'est pour ça que, quand vous faites des rebases interactifs
ou des rebases tout courts,
quand vous essayez de pousser votre branche,
Guy, il va vous dire,
« non, on ne m'attente pas le droit,
parce que la destination n'est pas en rapport avec Scottat,
elle est en avance, etc.»,
et il vous propose souvent de faire un guide pool,
de récupérer la distance, mais ne faites pas ça.
Et confiants sans vous,
vous savez que vous avez modifié votre historique,
vous savez que les comites ont changé
et vous faites un push-force comme Yoda,
ou là, mouah, vous forcez le comite.
Voilà ce que j'avais à dire là-dessus.
Vous avez des pièges à partager, tous les deux ?
Là, typiquement, c'est ce que tu viens de dire.
Attention, quand on fait un rebase,
ou dans ce qu'on disait, on fait un écrit historique,
ou quand on fait un cherry pick,
c'est prendre un comite qui a un endroit bien précis.
Ça change les comites ID.
Tout simplement pour la raison que tu as mentionné juste avant,
c'est que le parent, le potentiennement ne sera plus le même.
Donc il n'y aura pas le même comite ID.
Ce qui fait que, dans certains cas, si on se débrouille mal,
on peut se retrouver avec des historiques
qui ont deux comites dans un historique,
qui ont le même libélé, mais pas le même comite ID.
Voilà, ça fait un peu des pièges qui arrivent.
Moi, ce que j'encourage à faire aussi,
c'est quand même un outil complexe.
Et surtout au début, c'est à chaque fois qu'on passe une commande,
d'essayer d'aller voir que la commande a bien produit
ce qu'on espérait dans l'outil.
Exemple, si on fait une réécriture des comites,
on va aller voir le Log, faire le Git Log
pour s'assurer que la réécriture est celle qui était espérée.
Voilà, qu'est-ce que je peux te dire d'autre ?
Oui, un piège assez classique.
Attention aux éditeurs, c'est peut-être moins vrai aujourd'hui,
mais souvent les développeurs utilisent guide
à travers leur IDO,
donc IntelliJ, VS Code, etc.
Et IntelliJ, je pense que ça se passe pas trop mal maintenant.
VS Code, je sais pas trop, j'espère que c'est correct,
mais il y a eu parfois des soucis quand on fait un déplacement de fichiers.
Donc la commande, c'est Git MV.
Et quand on fait un Git MV,
Git va comprendre qu'on a renommé un fichier
où on l'a déplacé,
et donc il va conserver l'historique
de comment s'appeler le fichier avant
et le nouvel hystérique avec le nouvel fichier.
Et il y avait certains éditeurs qui vous aient passé bien
en faisant plutôt un effacent le fichier
en en recréant un nouveau,
et donc quand il a changé de ment au perdu de l'historique.

Je vais aller plus loin que toi en fait.
Faites attention aux éditeurs graphiques de Git.
Quand vous commencez,
moi je vous conseille,
je sais qu'il y a des gens qui sont pas d'accord avec moi,
mais moi je vous conseille de poncer la ligne de commande
pour bien comprendre ce que vous faites,
pour bien connaître les commandes,
et une fois que vous connaitrez bien les commandes,
vous pourrez passer sur des éditeurs graphiques si vous avez envie,
mais vous verrez tout de suite
à la longue que vous n'aurez plus envie
et que la ligne de commande est la plus efficace.
En fait la ligne de commande va vous permettre
de bien comprendre ce que vous faites.
Vous pourrez vous relire,
vous pourrez relire la ligne de commande,
vous pourrez vous dire ce que c'est ça que je veux faire.
Vous aurez moins de surprises.
Je puise soit complètement,
moi c'est le conseil que je donne,
alors il n'est pas forcément suivi,
mais je trouve qu'on a beaucoup plus la maîtrise avec la commande.
Peut-être pas tout à fait le dernier,
mais notre piège a évité,
grand classique,
Git s'est fait pour gérer des sources,
donc du fichier texte.
Donc il faut éviter de pousser des gros binaires.
On peut mettre quelques binaires.
Il y a d'ailleurs quelque chose qui s'appelle un fichier
qui s'appelle point Git attribute,
qui permet de définir qu'un fichier a un binaire.
Du coup ça va simplifier un peu la gestion pour Git,
il ne va pas forcément faire des diffs dessus,
parce que faire un diff sur un binaire,
ce n'est pas forcément très utile.
Voilà, mais s'il y a des gros binaires à gérer,
à noter qu'il y a deux projets qui existent,
qui s'appellent Git LFS
et puis un autre qui s'appelle
Git VFS qui fait par Microsoft,
et en gros, ce que ça fait,
c'est que le Git va être
comme un...
va stocker un peu des pointeurs
pour ces gros fichiers qui seront stockés
eux sur un file système.

Donc voilà, éviter de mettre des gros binaires,
c'est pas grave.
D'ailleurs,
Git LFS,
j'allais dire que Git LFS est intégré à Git là-bas.
Vas-y, y a un watch, c'est le seul truc.
Vous voulez juste se rajouter
qu'il y a binaires, mais il y a aussi bêtement
les images.
Sur les images, ça marche pas forcément bien non plus.
Et puis, pour les binaires,
il y a la fameuse histoire de Stop Covid.
Je ne sais pas si vous vous souvenez,
ils étaient...
Dans le cas des charges, ils devaient
versionner Stop Covid.
Et ce qu'ils ont fait, ils ont fait un
repo-Git avec
une archive où il y avait
le code, mais le code était dans l'archive.
Donc ils committaient le binaire,
autant dire que
Git ne serve à rien dans ce contexte.
Tu as la parole.
Gardes là,
parce qu'apparemment, t'as plein de pièges
à éviter à conseiller à notre évite.
Il y en a que vous avez
cité, le coût
des comites intelligibles.
Moi, je rajouterais
qu'il ne faut pas oublier que les comites,
il y a le...
Je ne sais plus comment...
le terme exact, mais il y a la première ligne,
l'espèce de Header. Et après, vous pouvez l'enrichir.
Donc quand vous faites un
Git commit, tirez M,
vous mettez le message. Et après, si
vous mettez tirez E, ça va vous ouvrir
votre éditeur de texte et vous pouvez rajouter
autant de lignes qu'il le faut.
Ça, ça peut être pratique, des fois,
pour décrire des choses qui ne tiennent pas
justement, juste...
Enfin, dans un commit message classique.
Et donc, bien sûr,
intelligible et évité ce que
tout ce qui a été cité par René et Christophe
il ne faut pas ravons avec les bugs,
oops, oh là là,
j'ai oublié des trucs, etc.
Je voulais aussi
rappeler que Git sous Windows,
alors peut-être que ça a changé, mais en tout cas
pendant très longtemps,
ce n'était pas la fête,
particuliers à cause
des majuscules et tout.
Il y avait plein de trucs
sur lesquels ça ne marchait pas bien.
Alors je ne sais pas si depuis,
il y a des changements,
mais en tout cas pendant très longtemps,
c'était galère.
Justement, tu parles de Windows,
j'ai eu le cas, parce que
j'ai travaillé avec un client
qui m'obligait à avoir un VPN
qui faut que ce soit sous Windows.
J'ai constaté que les retours chariots,
évidemment, les retours chariots
étaient changés à chaque fois,
parce que moi, je développais
avec ma station de travail Linux,
et du coup, je passais sur une VM
Windows pour comiter,
parce qu'il est derrière un proxy,
je ne vous fais pas les...
Mais du coup, ça a changé,
mais les retours chariots.
Donc attention,
à Windows, prenez votre Windows,
jetez l'œil et installez Linux sur votre machine.
C'est particulièrement pénible ce que tu dis,
parce que le retour chariots,
ce qui peut se passer, c'est que
dans certains cas,
on peut croire que toutes les lignes
ont changé.
C'est très pénible.
Ça s'aménuera, il y a eu beaucoup d'améliorations.
J'ai peut-être été un peu vite,
parce que si tu débuts en guide,
peut-être ne sais-tu pas ce que c'est
qu'un retour chariots.
Donc il faut savoir que dans ton fichier texte,
il y a du code.
Chaque caractère est un code,
et le retour à la ligne, le retour chariots,
est un code.
Et ce n'est pas le même code sous Linux
que sous Windows.
Donc ça pose en effet des problèmes.
Le fameux contrôlem,
qu'on voit sous Linux quand on a des
retours chariots Windows.
Je ne sais pas si vous l'avez déjà vu,
mais si tu l'as déjà vu, c'est ça.
Dans les autres trucs
que je voulais partager,
c'est un truc qui paraît idiot.
Mais si vous pliez, lisez les output
des commandes guides.
C'est souvent très bien fait.
Et les informations
que ça vous donne
sont souvent très pertinentes.
Alors il y a le classique
quand vous faites un guide statue,
ça va vous dire quoi faire après
si vous voulez commiter vos fichiers,
si vous voulez au contraire
ne pas conserver les modifs,
etc.
Mais même sur des opérations
qui peuvent paraître intimidantes,
comme merger
des conflits
quand on doit merger
par exemple une branche.
On dirait une branche.
En fait,
suivez ce qui est écrit.
C'est
vraiment
très très bien fait.
Et souvent
je me suis aperçu
que dans les élèves que j'ai,
des fois ils me disent
je ne comprends pas ce que je dois faire,
je suis bloqué.
Et en fait il y a juste marqué,
t'es un conflit.
Est-ce que tu veux garder telle version,
l'autre version.
Voici
les guides
dans la Output, il y a souvent
la commande à taper.
Donc vraiment,
faut lire ça parce que c'est
vraiment un truc
enfin c'est basique
de lire les logs,
mais faut vraiment le faire.
Je suis profondément d'accord avec toi
et j'ai remarqué exactement le même souci.
Donc ça veut dire que c'est
commun chez tout l'invis,
lisez les sorties de guides.
Surtout qu'en plus si vous êtes sous Linux
ou même sous Windows je crois que ça le fait,
vous avez des couleurs
donc c'est encore plus lisible.
Par contre attention quand même,
ne faites pas tout ce que dit guide,
vous propose de faire, réfléchissez,
parce que c'est vous qui devez
commander à guide et pas le contraire.
Exactement.
Un autre truc qui paraît
évident, mais qui est toujours
bon à rappeler parce que
je vois ça trop souvent,
qui est ne pas commuter
des secrets en clair dans vos
hippos. Il y a plein de méthodes
pour
ne pas avoir à faire ça.
Ou
comité des choses qui sont chiffrées,
etc.
C'est ce qui arrive,
par exemple quand on fait du Antibol,
souvent on utilise le AntibolVault
pour chiffrer
des fichiers avec des secrets.

donc du coup,
évitez ça.
Je crois que c'était tout.
Alors justement,
nous on utilise pour ça
des hooks de pré-commit.
J'en ai parlé dans AdMai Live,
donc ça permet,
les hooks, ça permet
du coup,
guide, il y a des événements récompris en local.
Ça permet d'éclencher des actions
sur l'événement de comites.
Et donc le hook, si vous le
codez évidemment, vous allez pouvoir regarder
si c'est un secret, si c'est un secret
qui n'est pas chiffré, vous allez pouvoir
arrêter là, dire
attention, ton secret il n'est pas chiffré,
tu ne peux pas faire de comites.
Chiffre là d'abord.
Voir si vous allez plus loin, le chiffrer
automatiquement.
Donc
voilà et puis après,
il y a quand même pas mal de petites choses
que
qu'on peut éviter facilement
en utilisant intelligemment le guide ignore
qui est donc un espèce de fichier
dans lequel vous dites, quoi qu'il arrive,
ce truc là, il ne faut pas que ça se retrouve
dans mes comites.
Et ça peut,
enfin souvent quand on le set pas très bien,
on peut avoir des surprises quand on
fait des
ajouts un peu massifs on va dire.
Et donc du coup,
faites attention à bien utiliser ça
si amement.
Alors on a parlé un petit peu
du push force,
René, tu voulais nous en dire un petit peu.
Oui, ça c'est un classique.
Alors moi je trouve que
comment dire.
La façon dont c'est nommé
et voilà, peut-être pas terrible
le tiref pour force.
Mais un des pièges,
il faut jamais faire un push force
forcément sur un dépôt qui est public.
Donc il faut penser,
alors je pense que c'est globalement
le cas sur GitLab.
Voilà, les branches sont souvent
protégées.
Mais il faut se méfier, voilà, la branch
de référence doit être protégée.
Histoire peut être que personne
ne puisse la réécraser
par mes gardes.
Oui, alors quand tu parlais de dépôt public,
tu voulais dire la branche principale
du dépôt parce qu'on peut
faire d'un push force sur les branches
à côté.
Oui, bien sûr, ça branche personnelle.
C'est difficile de trouver un nom
mais entre guillemets public,
c'est entre guillemets une branche qui va être
récupérée par différents
contributeurs.
Voilà, c'est en ce sens là.
Et une branche privée, c'est sa branche personnelle.
Donc sur sa branche personnelle,
il n'y a aucun problème, on fait faire ce qu'on veut.
Par contre, il faut absolument éviter
de faire un push force
sur la branche qui est récupérée par tous les autres.
Sinon on va échanger potentiellement les comités ID.
Et tous ceux qui sont basés sur
qui ont récupéré le repo,
ça a plus de sens parce que les comités ID
ont changé et du coup c'est le gros bazar.
Donc il y avait un document
sur, j'essaierais trop mettre le lien,
il y avait un document
sur la doc de guide
qui mettait quand on arrivait un peu
dans les dangers zone.
Donc il y a parfois des erreurs
qui vont mieux de laisser plutôt qu'essayer
de décoriser parce que
ça peut encore empirer,
encore plus la situation.
Et juste un autre petit truc
je ne sais pas si vous en avez parlé
de BFG.
Attends, juste je vais
continuer là.
J'avais fait une vidéo justement
sur comment protéger et sécuriser
les dépos GitLab et je parle
justement de la protection des branches
principales.
Comment est-ce qu'on fait et je pense qu'on peut
faire la même chose sur GitHub.
Je te laisse la parole pour BFG.
Oui, BFG en fait c'est un outil
fait par GitHub justement
pour justement aller effacer
les secrets dans un repo Git
parce que bien sûr il ne suffit pas
d'effacer dans le
dernier comite.
Sinon ce serait trop facile et donc il y a
tout un tas d'outils qui sont effets
pour aller chercher les secrets
dans les repository
Git et pour effacer
un secret qui est liqué
proprement.
Donc il y a un outil qui est effet
qui s'appelle BFG
qui permet de faire ça de manière assez
simple parce que sinon c'est assez
compliqué pour aller purger
tous les potentiels comites
qui contiennent le secret.
Voilà, un outil à connaître
mais je rejoins
AirOne sur le fait que le
mieux c'est de pas comiter de secret.
Donc utiliser des Gitooks.
C'est important les Gitooks.
On va
tu l'auras compris en fait
il y a beaucoup de pièges à éviter quand on
commence Git mais après tu vas devenir un ninja
pour esquiver ces pièges là
et quand tu deviens un ninja pour esquiver
ces pièges là tu peux commencer à
travailler en équipe.
Mais là vraiment tu vas commencer à
travailler en équipe et donc il y a
plein de choses à dire sur Git
et le travail d'équipe.
Et c'est AirOne qui va commencer
cette partie là.
Oui, comme
vous l'avez dit
un peu plus tôt c'est que
Git, une fois que vous êtes à l'aise
il y a quand même pas mal de pièges
à éviter. Donc ça veut dire
que quand on travaille en équipe il faut se synchroniser
pour être sûr de ne pas reproduire ces pièges.
Donc ça c'est la première étape.
Et après
il se passe que
comme vous allez travailler ensemble avec
votre équipe, il va falloir
avoir une méthode de travail
autour de votre repo
et c'est ce qu'on appelle
le flow
en fait de développement.
Et le flow
de développement du coup
ça va être
votre façon
de faire des incréments
en gros sur la
branche principale de votre projet.
De façon
collégiale avec
vos collègues.
Je ne sais pas si vous
avez une autre définition
ou si vous voulez apporter
une précision
à ça déjà.
Oui, j'ai fait
une vidéo justement sur les flux de développement
Git
lequel choisir et j'en ai présenté trois
justement trois flux
qui sont assez courants là dessus.
Je vous mets les liens en description.
Et du coup
moi je peux parler très brièvement
de ce que je fais dans la boîte où je
suis actuellement. Donc comme disait
Christophe, il y a plusieurs
flows on va dire
populaire qui sont souvent
liés à la plateforme sur laquelle vous développez
puisque il y a un
GitHub workflow
et il y a un GitLab
workflow etc.
Et souvent
comme dans beaucoup de cas
l'idée c'est pas forcément d'appliquer les trucs
et que bêtement
d'un flow plutôt qu'un autre
c'est d'essayer de prendre
les bonnes idées des uns et des autres
pour forger ce qui vous intéresse
le plus.
Donc très brièvement, nous chez tout
ce qu'on fait c'est qu'en gros
à chaque fois qu'on veut faire un
incrément de code, on se crée
une branche sur laquelle
on va faire notre développement.
Donc sur laquelle on va pouvoir faire
autant de comites qu'on veut.
D'ailleurs souvent
on fait pas très attention aux comites
qu'on fait. Il y a beaucoup de gens qui font
pas très attention aux comités
qui font dans leur branche
qui est personnelle.
Une fois que
leur code est convenable
et que ça passe la CIA
il demande une review
à deux collègues.
Les collègues valident
tout ce qui va bien
sur l'approche de code etc.
Et donc après arrive le moment
de ok, j'ai
une branche avec plein de changements
que je maintenant rapatriez
sur la branche principale.
Nous, personnellement ce qu'on a
choisi c'est pour ça qu'on se permet
de dire on s'en fiche un petit peu
des comites que tu as fait sur ta
branche personneuse et qu'on squashène
le marché. C'est à dire que toutes les
modifications que la personne a fait
sur sa branche, on en fait un seul comite
sur lequel on met
un titre explicite
et ce comite
explicite est rapatrier
sur la branche
principale.
On fait du squashène
marche comme ça.
Et ça permet
d'avoir un historique
guide relativement
plus clair
puisque du coup c'est un peu ce que
expliquerons-nous un peu plus tôt.
C'est que chaque
comite correspond à un changement
important
du code.
Du coup ça évite tous les
petits comites intermédiaires qui
souvent sont pratiques pour la review
puisque c'est toujours plus facile
de voir des petites choses plutôt
qu'un gros bout de code en revanche qui
sont souvent pas forcément pratiques pour
l'historique et suivre la vie
du projet en termes de big picture.
Vous vous
avez des... vous appliquez
quel flow et pourquoi.
Rene.
Globalement
moi c'est
guide branching model plus
ou moins standard.
La plupart des clients on fait
le guide flow classique
parce qu'on a souvent obligé de
maintenir plusieurs versions parallèles
parce que ce qui est déployé en pro
et pas déployé ailleurs.
C'est plus ou moins le
guide branching model standard
qu'on trouve un peu partout avec des
fois quelques petites modifications
sur les noms des branches des choses comme
ça.
Nous on est
plutôt sur le guide
flow même si on travaille sur guide lab
donc ça veut dire qu'il y a une branch
principale et des branches de
fonctionnalité.
Nous depuis guide lab notre flow
est hyper clean parce qu'on crée les issues
donc on essaie de les faire les plus
petites possible et en fait
on utilise guide lab qui nous crée la
branche, on récupère la branche
après on travaille
on envoie nos
comites sur la Merge Request
qui était créée directement depuis
les issues.
Ce qui permet de tout fermer à la fin.
On essaie aussi de scocher
les comites sauf parfois
et c'est intéressant de garder 2-3
comites plutôt qu'un seul.
Donc ça c'est en fonction du travail qu'on
est en train de faire.
Ça dépend.
Et une fois qu'on a fini
on merge, on fait des comites de
Merge chez nous.
Il y a les comites de
fonctionnalité plus le comite de Merge
donc à chaque fois qu'on fusionne
on a un comite particulier qui nous
dit bah voilà il y avait une branch
à ce moment là et bah elle a été
fusionnée. Ça nous permet de garder
l'historique des branches et c'est sur
ces comites de Merge qu'on va pouvoir nous
aller mettre nos tags de release par
exemple. Voilà
comment on fait chez nous
et je sais qu'il y
y avait un débat dont on va parler
qui est le débat Merge-Ribas
et donc je vais vous dire justement
puisque je suis dans le...
dans notre méthode de travail chez nous.
Donc Merge-Ribas. Merge
ça fait un comite souvent
alors que Ribas on réécrit
l'historique pour changer le comite
d'origine d'une branch.
Alors nous ce qu'on fait c'est qu'on
Ribas depuis la branch
principale nos branches
ce qui fait qu'on
n'a pas de comites de Merge sur nos
branches par contre quand on vient
fusionner nos comites de fonctionnalité
sur la branch principale on a
un comite de Merge ce qui nous permet
d'avoir uniquement les comites
de Merge de fonctionnalité.
Oui bah... enfin globalement pareil pour...
enfin...
moi j'aime bien cette option là parce
que je trouve qu'une des forces c'est que ça rend
souvent l'historique plus facile à lire
et quand... voilà
donc plutôt de cet écode là aussi.
Bah...
Tu as aussi Erwan à part avant, tu piques du chef?
Non, je suis d'accord avec ce que vous dites
mais après comme je vous disais là où je suis
nous on a ce côté
donc sur les branches perso
en gros tu fais ce que tu veux
et tu fais ce que tu veux aussi pour
te mettre à jour par rapport au
à la branch principale
donc tu...
tu arrives, tu fais ce que tu veux
par contre du coup quand
on rapatrie dans l'autre sens
donc de la feature vers la branch principale
là on est sur le Squash & Merge
et du coup on n'a pas ce comite de Merge
comme décrivé mais
moi je n'ai pas trop d'avis sur
je trouve que dans les deux cas c'est lisible
le seul truc
que je trouve bien dans le Squash & Merge
c'est que justement les gens qui
qui ne font pas forcément le bon effort
côté
de leurs branches perso au final
ça se voit pas.
En fait tu vois moi le problème parce que justement
tu Squash & Merge, du coup à chaque fois tu as un comite
du coup c'est pas mal
mais si tu le fais pas
tu vas avoir un peu des
si tu fais des... si tu rebesses pas
tu peux avoir des espèces de
d'interlivre
je ne sais pas forcément
entre guillemets, tu as des comites qui sont
qui ne sont pas agencées
proprement
Oui exactement
j'ai vu ça parfois
je travaillais parfois avec des développeurs qui faisaient pas ça
qui mergaient
à l'intérieur de leurs branches
et puis après quand tu remergais dans la branche principale
ça faisait un graph. C'est vrai qu'on n'a pas parlé du graph
mais c'est un outil que j'aime beaucoup
le graph nous permet de voir
comment les comites sont agencées
quand on ne fait pas des Squash & Merge
on a un graph souvent
quand on fait un Squash & Merge on n'en a pas
parce que c'est tout beau, tout propre, tout droit
mais quand on ne le fait pas
on peut avoir des graphs
on voit les branches, les anciennes branches
qui reviennent, qui se repliquent etc
et le graph
quand vous débuguez Guite c'est essentiel
comme ça vous pouvez comparer
votre serveur et vos branches locales
quand vous êtes perdu dans vos branches
parce que ça arrive
les néophytes ils se perdent dans les branches
et ils ont des problèmes
quand ils font des actions
en regardant le graph on voit les problèmes
qui se sont passés
qu'utiliser le graph c'est bien
il y a une petite astuce
quand on rapatris justement
qu'il y a plusieurs comites
on peut le faire en Fast Forward
du coup là tous les comites vont se retrouver
dans le graph aligné
et parfois ça peut être sympa de le faire non-Fast Forward
de manière voulue pour bien materialiser
dans le graph
que c'est une branche de features
avec un ensemble de comites
qui a été merduée
après c'est un peu les goûts des couleurs
mais bon
Erwin tu voulais nous parler
d'Alias
Guite
comme on le disait un peu plus tôt
Guite ça peut être vite intimidant
il peut y avoir les commandes
peuvent être un peu complexes
parfois
ou du moins difficile à retenir
et surtout des fois
vous allez faire des commandes
pipez des trucs
qui va vous répondre
à un besoin spécifique
et à retrouver du coup
c'est souvent l'angoisse
ce qui est bien c'est qu'on peut créer
des alias dans Guite
et un peu d'autopromos
pour tout quand j'avais écrit un article
où justement je donnais
quelques alias que
moi j'ai dans mon
dans mon environnement
et par exemple
il y a un truc
ça va pas être très déma go
mais je supporte pas le guide blame
je comprends pas pourquoi on a appelé ça blame
alors que moi je veux
au contraire féliciter les gens
je veux pas chercher qui a écrit un truc
en le poitant du doigt
donc moi j'avais mon alias
guide blame c'est guide congrat
et bon ça c'est pour la blague
mais après il y a des trucs un peu plus intéressants
pour retrouver moi souvent
je recherche
des comites que moi j'ai fait
et souvent
c'est un peu galère
il y a un alias pour ça
qui permet de récupérer uniquement
vos propres comites
avoir des stats sur les comiteurs
sur des périodes
c'est un petit truc sympa
et encore une fois ça montre à quel point
la ligne de commande avec guide
elle peut être hyper puissante
et vous pouvez faire des trucs chouettes
et du coup au lieu de vous en rappeler
vous créez des alias
vous en avez vous
alors oui moi j'en ai
et je vois que tu es fan de béson
en voyant tes alias
on trouvera le lien en description
moi j'ai des alias
j'utilise homoizé des sages comme shell
homoizé des sages c'est merveilleux
alors du coup
j'embraye
je spoil un peu la partie productivité
mais homoizé des sages c'est merveilleux
et du coup dans homoizé des sages
il y a plein d'aliases sympa
par contre je déconseille d'utiliser
les alias au début quand on commence guide
il faut vraiment taper les lignes de commande
pour bien les comprendre pour savoir ce qu'on fait
et après on peut utiliser les alias
parce qu'on sait que les alias correspondent à quoi
si on commence à utiliser les alias direct
on sait pas ce qu'on fait
par exemple moi j'ai un gg push
mon gg push ça me permet de pousser
sur la branche sur laquelle je suis
sur le dépôt distant
c'est un guide push origine ma branche
et bah si tu sais pas ça
est-ce que tu tapes gg push au bout d'un moment
si tu vas aller sur un terminal
il n'y a pas le gg push tu vas taper ton gg push
et puis tu vas te dire pourquoi ça marche pas
voilà
petit info
c'est bizarre moi j'utilise pas d'aliases
mais je pense que c'est pour
justement mieux retenir les commandes
et puis des fois je vais dépanner d'autres personnes
du coup ils n'ont pas forcément
ces alias là
c'est un des trucs que je fais pas forcément
justement on parlait tout à l'heure
de flû et de fusion
et parfois on a des
merges conflict dans des conflits de fusion
oui alors bah
et tu voulais nous en parler oui
excuse-moi
oui oui en fait c'est
effectivement l'intérêt de guide
c'est effectivement nous aider quand il y a des conflits
donc un conflit c'est quand
deux portions du même fichier ont été modifiées
par exemple par deux personnes différentes
et donc là il n'y a pas de magie
guide va nous demander quelle est
la vérité
qu'est-ce qu'est le code valide
il va falloir gérer ce conflit
maintenant
c'est un petit peu le corollaire de ça
un guide c'est un super outil
c'est super puissance
peut-être le meilleur outil du monde pour gérer
nos sources
mais ça n'empêche pas de faire tout le travail
à mon côté
gestion du projet
sur le découpage des features
essayer de les découper
enfin essayer de faire des
découpages les plus fins possibles
pour limiter la taille des changements
donc ça fera des comines plus petites plus faciles à intégrer
et puis bah aussi de la même manière
si on donne la même chose à faire
à deux développeurs
forcément ça va faire des conflits
donc voilà et ça
malgré qu'on ait un outil extrêmement puissance
il y a toujours une grosse partie du travail
de bien ça
enfin d'essayer de découper au mieux
les changements
et les nouvelles features qui vont arriver
dans la code base
et bah on va parler alors de productivité
et je vous ai un peu spoiler ça
parce que je vais vous parler de
omai zdsh
alors omai zdsh c'est
en fait c'est un surplus
de zdsh
zdsh c'est un shell script
excusez moi
je sais c'est un tard c'est tard
il est 21h passée
c'est un interpreter de commande
qui remplace le bash
ou le shell si vous avez le shell
et omai zdsh
ça rajoute des fonctionnaires en plus
et notamment
tout un tas d'aliases, tout un tas d'outils et de plugins
et moi j'utilise un thème particulier
qui s'appelle le thème agnoster
que je vous conseille
qui se base sur la powerline
donc il y a une ligne
de prompt en fait
avec des couleurs et qui vous donnent
tout un tas d'informations
liées à git
notamment vous savez tout de suite
quand vous êtes dans votre terminal
si vous avez des fonctionnalités
enfin si vous avez des modifications
qui ne sont pas versionnées
si vous avez mis
des modifications
dans le côté
mais que vous n'avez pas comité
ou si
ou sur quelle branche vous êtes
ça c'est essentiel
parce que si vous ne savez pas
sur quelle branche vous êtes
et si vous vous faites confiance à votre cerveau
vous allez vous planter
c'est évident
donc moi je vous mets les liens
de omai zdsh en description
et si vous êtes sous Linux
je vous conseille de l'utiliser
et si vous n'êtes pas sous Linux
je vous demande ce que vous faites là
à écouter Radio DevOps
à force de vous dire de passer sous Linux
je troll un peu
mais je vais laisser la parole à Roné
alors oui
ça a mis ça dans le long des productivités
donc oui c'est vrai
en fait ce qu'il faut voir c'est qu'il y a beaucoup de commandes
il y a plusieurs manières
de faire les choses
et il y a des commandes
de plusieurs raccourcis
donc j'avais mentionné tout à l'heure le fameux
Geatrim of the Update
qui peut avoir un équivalent avec GeatFetch
MoWl etc
donc il y a pas mal de choses comme ça
c'est à la fois à mon avis une force
mais aussi peut-être une faiblesse
surtout au début
voilà la commande line
est parfois plein de raccourcis
mais il faut me postméfier de ça
et parfois la consistance des commandes
pour moi c'est un autre défaut
peut-être un peu douteuse
même si ça s'amène
il y a quand même malgré les en fonction des versions
des nouvelles versions
il y a des choses qui s'amènent
tout à fait
et moi ce que je peux vous dire
pour améliorer votre productivité
c'est il faut t'entraîner
t'entraîner avec Geat
et en fait ça doit pas devenir une douleur
l'utilisation de Geat ça doit devenir une habitude
et donc pour ça je vais faire de la pub
pour un de mes concurrents
je vais vous parler d'Atlassian
qui édite beat bucket
et donc ils ont un site d'entraînement
un guide qui est assez bien fait
il y a plein d'infos dessus
je vous mets le lien en description
allez-y
et puisque j'ai la parole
je vais la garder
tout à l'heure on a parlé des guide hook
et donc moi je ne peux que vous encourager
à mettre des lineteurs
dans vos guide hook
et notamment je vous en ai décoité quelques uns
il y a le commit lint
qui vous permet de linter
vos comites conventionnelles
on vous en a parlé vos messages de comites
pour voir si ils sont
en rapport avec ce que vous avez dit
et puis sinon je vous mets
d'autres lineteurs
il y a GeatLint et PreComit
qui sont en fait des lineteurs
vous pouvez utiliser en fonction de comment
vous décidez de faire vos comites
vous pourrez les linter
et vous vous en avez décoité
avant de les envoyer sur le serveur
ce sera pas mal
est-ce que vous avez d'autres conseils de productivité
moi je veux juste dire
que les guide hook ne se substitue pas
à la CIA
et ça on le voit trop souvent
non c'est vrai
c'est un complément essentiel
pour éviter d'attendre le retour
de la CIA
mais si vous n'avez pas
de complément en productivité
je vois qu'on discute quand même depuis
1h15
je vous propose qu'on s'arrête là
et on voulait parler
un tout petit peu aborder quelques mots
pour vous faire un teasing sur un prochain épisode
mais Geat
a apporté pas mal de choses
et notamment nous a apporté le GeatOps
qui fait pas mal parler du en ce moment
et je pense qu'on fera un épisode
spécial sur le GeatOps
l'année prochaine
enfin non cette année
puisque quand on enregistre on en 2021
mais quand vous écoutez
vous êtes en 2022
donc voilà
avant de laisser
le dernier mot
à mes chers co-animateurs
si tu as apprécié ce podcast
et si tu as appris des choses
et si tu veux nous soutenir
tu peux faire un petit don sur Libérapay
Libérapay c'est une plateforme de dons libres
je sais pas si j'en ai parlé
parce qu'on me demande parfois s'il y a un Tipeee
mais j'ai choisi Libérapay parce que c'est basé sur un logiciel libre
c'est géré par une association française
et donc j'ai trouvé que c'était pas mal
il y a pas mal de logiciels libres
justement qui se financent avec Libérapay
et quand on crée du contenu libre
comme le nôtre
c'est parfois compliqué
et moi je vais laisser la parole
à René pour le mot de la fin
wow
ben oui
je vais encourager les gens
à donner sur Libérapay
surtout que tu te compares
à Atlassian
comme concurrent
c'est pas le plus petit
il va falloir faire beaucoup de dons
pour arriver à concurrencer
Atlassian
voilà après
qu'est ce que je peux dire
un guide d'Lemme c'est de l'humour à la Linus
en mot de la fin je vous dirais d'aller chercher
ce que veut dire guide en nareau anglais
et
et Erwan
ton mot de la fin de la fin
comme
il y a eu la faille de l'Octford G
ce sera
java
merci d'avoir écouté Radio DevOps
n'oublie pas de nos télébizodes
plus la note sera élevée
et plus sera mis en avant
dans les applications
tu peux aussi le partager
ça nous aidera à le diffuser
et à rendre le mouvement plus visible
si tu as envie de discuter du mouvement
alors rejoins nous dans la communauté
des compagnons du DevOps
à bientôt
la baladeau diffusion des compagnons du DevOps
est produite par Lydra