017. La gestion de versions du code source
Comment gérer les flux de travail autour du code ?À la table, Ronan Limon Duparcmeur, Jérémy Lecour, Céline Martinet Sanchez et Christophe Philemotte.
Télécharger l'épisode (20 Mo) - Date de publication : 2017-06-12
Comment gérer les flux de travail autour du code ?
Pourquoi versionner ?
Toutes les histoires d’horreur :
- le dev seul ou qui n’a pas envie d’y passer, qui fait des FTP, des CP et des .bak
- les histoires de sauvegardes perdues, de modifications à plusieurs, de synchro…
- l’envie de faire une expérience dans un coin et d’avoir du mal à les fusionner
C’était pas du tout quelque chose de gagné, mais ça devient quelque chose de base (bootcamps…).
Git pour le code, mais aussi la doc, le contenu, la rédaction à plusieurs.
Distribué : tu fais tout ce que tu veux en local et, éventuellement, tu envoies sur le réseau.
Comment gérer les flux de travail autour du code ?
À la fois l’utilisation basique des outils, mais aussi la manière de faire collaborer une équipe, les motifs de fonctionnement, les techniques de communication…
- GIT, git-flow
- forked
- trunk/based
- gitflow
- rebase versus merge
Bottes secrètes, super astuces, tips and tricks
Christophe :
- simuler un merge avant de le faire.
- récupérer le point d’origine d’une branche
- puis merge tree (diff entre la tête de la branche et l’origine de la branche et output du diff)
- on peut alors ouvrir l’output pour le consulter.
- https://github.com/toch/gitils/blob/master/aliases.sh#L17
Reflog : historique de toutes les commandes tapées + sha de tous les commits.
squash
Jérémy : https://speakerdeck.com/jlecour/introduction-a-git-et-workflows-marsjug-2011 (c’est très vieux mais toujours valable). http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
Influence des outils sur l’organisation
- C’est systématique mais on part avec des croyances sur l’utilisation des outils.
- Mais il faut adapter le workflow en fonction de l’organisation.
- Les review pre ou post-commit, etc.
Les outils influencent l’organisation (la loi de Conway) : “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”
PR et contrôle de source sur Github
L’art d’un bon message de commit
- @flexbox parlait de http://karma-runner.github.io/1.0/dev/git-commit-msg.html
- @abelar_s je suis pas fan mais j’ai pas de meilleure ref, juste une citation
votre commit doit être écrit pour compléter “si appliqué, ce commit…” (“corrige l’issue 11”, “ajoute un champ aux users”, “ajoute la gestion des impayés”)
- Attention aux messages “retour de PR”, “jardinage”, “balai” … Les commits fourre-tout.
- La règle du boy-scout : le nettoyage doit aller au tout début de la PR et pas au milieu !
=> C’est un guide de style aussi, à définir dans vos équipes
- @celine_ms le git log qui donnera un historique intéressant
- @r3trofitted des messages très complets après avoir fait une belle feature
- le message de commit qui sert de documentation
Découvertes des invités
- • Jérémy Lecour
- Et se replonger dans de vieux titres souvent samplés depuis – B-Boys - une histoire du break
- • Christophe Philemotte
- Des bruits de nature ou d'animaux, en bruit de fond delaxant. – Noisly, bruits relaxants
- • Ronan Limon Duparcmeur
- par Jean-Michel Queguiner (l'article est en rapport mais c'est pas 100% ça) – Des seminaires sur l'importance de la chaleur humaine
- • Céline Martinet Sanchez
- Automatisation, emplois obsolètes, IAs, revenu de base... – Discours de Mark Zuckerberg sur le futur de l'emploi
- Comment mes recherches en IA ont mis mon papa au chômage