Le topic de la programmation: Et envoyez des sioux!

[Awake]

git poule

est tellement plus fun et facile à faire avec les aliases.

[Taro]

J'aurais plutôt tendance à faire un alias pour qu'un pull fasse apparaître un message indiquant de faire un fetch et ensuite un rebase ou un merge en fonction. Avec insultes en option.

[deathdigger]

git checkout <hash-du-commit> de mémoire

On ne dit plus "master" c'est stigmatisant.

Mais sinon le versioning à la git il faut un peu changer de point de vue. Tu n'as pas un code monolithique avec différentes versions, tu as ton dépôt qui contient le code dans sa globalité, et ce code aura plein d'états différents, et à chaque commit tu vas créer un nouvel état. L'intérêt c'est de pouvoir y mettre tout ce que tu veux (les versions release bien propres, les betas pas encore sûres à 100%, des fonctionnalités expérimentales pétées....) et de facilement y naviguer (tu passes d'un état à un autre facilement, mais c'est beaucoup plus riche que "faire du rollback"), le défaut c'est que tu dois gérer toi-même où tu mets les choses.


En solo il suffit de se cantonner aux recommandations classiques comme dit plus haut :
- la branche master contient le code en état "prod" (ça a été testé, ça compile et ça tourne)
- des branches secondaires pour les évolutions du code qui ajoutent de nouvelles fonctionnalités, modifient la structure fondamentale du code ou ont de gros risques de tout péter

Et à la fin, soit ta branche secondaire est abandonnée et elle reste morte, soit elle arrive à un état satisfaisant pour être intégrée au master et là tu vas faire un merge. Le truc un peu délicat à comprendre c'est que ce genre d'opération ne modifie pas le code en lui-même mais l'état du dépôt.
En faisant le merge tu vas créer un nouvel état où le code contient ce qui a été fait dans le master et dans la branche, la branche en elle-même existe toujours et tu pourras toujours remonter l'historique de ses commits, repartir dans de nouveaux développements indépendants après le merge, etc...

La grosse question dans l'affaire c'est à quelle granularité tu décides de créer une nouvelle branche dans le code... et c'est là que les prises de têtes arrivent quand tu commence à avoir beaucoup de monde qui développe en même temps sur un même dépôt. Certains aiment créer une branche pour le moindre caractère modifié, si tu es seul ou presque à modifier le code c'est pas franchement utile pour ce qui n'a pas ou peu d'impact sur la structure générale du code (bugfixes localisés, docu, fichiers de config pour une nouvelle machine...).

Pour le nommage des versions ça se passe par les tags qui consistent juste à mettre un nom compréhensible sur un commit particulier.

Un exemple de workflow typique :
- tu commence le développement de l'appli de manière linéaire
- moultes commits dans le master (à chaque fois qu'il y a un morceau de plus implémenté qui compile et tourne bien)
- le code atteint un état où tout ce que tu voulais mettre semble fonctionner correctement => tu le taggue "Version 1.0" ou "beta" ou ce que tu veux
- tu as une idée de nouvelle fonctionnalité fabuleuse : tu crée la branche "THIS_IS_NOT_A_FEATURE_THIS_IS_A_REVOLUTION" à partir du commit taggué "Version 1.0" et commence des développements dessus
- entre-temps des utilisateurs t'ont fait remonter 4 bugs
- tu corriges ces bugs dans 4 commits individuels que tu push sur la branche master
- tu te dis que tous ces correctifs méritent d'être mis en avant : tu taggue "Version 1.1" sur le dernier
- tu reprends le développement dans ta branche révolutionnaire mais tu te dis que c'est dommage de ne pas avoir ces nouveaux correctifs de la 1.1
- Et là magie de git, tu as ce qui est une des meilleures features de ce système de versioning : le rebase. Tu vas dire à git : je ne veux plus que la base de ma branche parte du commit "Version 1.0" mais qu'elle parte du commit "Version 1.1". Et voilà, en une commande toute simple tu as mis à jour le code de ta branche avec tout ce qui avait évolué parallèlement dans le master.

Merci pour les infos, faut que je teste ça avec un projet bidon

[Frypolar]

Je comprends même pas 1/4 de ce que vous dites, suis trop vieux pour ces conneries
Là je suis en train de chercher la meilleure façon de gérer le versioning du code-source (pour pouvoir faire notamment des rollbacks si besoin).
En gros, j'ai un code source que je veux sauver avant de modifier.
J'imagine que je dois passer par des branches, mais je ne sais pas trop si c'est la bonne façon de faire.

Ce que je ferai spontanément, c'est faire une branche à partir du master et considérer que c'est ma version 1.0
Ensuite, je redéveloppe sur le master pour faire ma version 1.1. En gros, la 1.0 serait une branche morte si je n'ai pas besoin de faire de rollback. J'ai bon, ou ce n'est pas la bonne direction ?

Le plus simple (et le plus efficace a priori) c’est ce dont parlait Kamikaze au-dessus : trunk-based development. Les trucs types gitflow c’est la solution parfaite pour avoir un sac de nœuds pas possibles avec ses branches. C’est aussi parfaitement opposé au principe d’intégration continue, par définition.

Le système trunk-based development est aussi particulièrement adapté à un débutant de git. Tu ne rencontreras jamais (ou rarement en équipe) de situations qui te demanderont un usage avancé de git.

Pour le scénario que tu évoques c’est aussi très simple avec ce modèle. C’est comme tu as dit. Si jamais tu veux qu’un changement fait sur la branche principale (master/trunk) arrive sur ta branche de release, typiquement une correction de bug, tu fais un cherry-pick de master vers la branche de release du commit qui a fait ce changement. Tu peux aussi faire dans l’autre sens mais il y a un risque d’oublier de pousser un bugfix de la branche de release vers master. C’est expliqué ici.

T’as aussi d’autres sites moins moches sur le sujet

[Dross]

C’est aussi parfaitement opposé au principe d’intégration continue, par définition.

J'vois pas bien en quoi. Tu peux avoir des règles de build/test/etc sur toutes les branches, même les temporaires de développement de features. Et ton déploiement automatique sur ta branche develop pour ton environnement de DEV, la master pointant sur ta prod.

Par contre oui, le meilleur workflow dépend de ton équipe/projet/etc. Trop lourd pour un projet trop petit c'est contre-productif. Et l'inverse est vrai aussi.

D'ailleurs c'est vrai pour tout les trucs de gestion en général : Agile tu prends ce qui t'aide, et tu vire ce qui t'emmerde.

[Frypolar]

J'vois pas bien en quoi. Tu peux avoir des règles de build/test/etc sur toutes les branches, même les temporaires de développement de features. Et ton déploiement automatique sur ta branche develop pour ton environnement de DEV, la master pointant sur ta prod.

Le principe de GitFlow c’est de faire des longues branches par feature. Une ou plusieurs personnes bossent dans leur coin, quand elles ont fini la branche est mergée dans develop. Ça peut durer un jour comme plusieurs semaines. D’expérience c’est plutôt une semaine en moyenne. C’est un modèle qui favorise les merges de taille assez conséquente.

Le principe de l’intégration continue c’est que tous les développeurs mergent leurs changements dans la même branche (typiquement master ou trunk) tous les jours voire plusieurs fois par jour. Le but est justement d’éviter les gros merges. À chaque merge on valide les changements par un build et des tests. Aujourd’hui on automatise cette partie et cette automatisation est abusivement appelée "intégration continue" puisque c’est le seul truc qu’on peut te vendre. Sauf que ce n’est pas l’automatisation qui rend le code plus robuste, c’est le fait que les participants mettent tous leurs changements en commun fréquemment. Si tu regardes un peu l’historique de cette pratique c’est très clair : à l’époque il n’existait pas d’outil pour automatiser tout ça :D

C’est comme un œuf à la coque. Si tu veux un œuf à la coque c’est 3 minutes dans l’eau bouillante. Si tu le laisses 10 minutes t’as un œuf dur. C’est bon aussi mais c’est pas pareil Pour une branche de dev, moins d’un jour c’est considéré comme "continue". Au-delà ce n’est plus le cas. Mais c’est pas pour autant que ça ne fonctionne pas.

Edit : et l’intégration continue c’est vraiment dur à mettre en place, surtout quand on est habitué à une autre pratique type gitflow. Le principe c’est de changer ta façon de travailler, ça pique un peu C’est d’ailleurs la grosse arnaque des boîtes qui te vendent du CI/CD comme étant une simple case à cocher. Tu te retrouves avec un build continue, rien de plus. C’est déjà bien mais rien ne prouve que cela amènera les bénéfices attribués à l’intégration continue.

[Anonyme20240202]

Par défaut git pull peut rebase depuis un moment ou avoir le comportement que tu veux (ff only), me semble que git te dit même de le configurer via un message si c'est pas le cas, donc c'est clean de nos jours. Et en vrai comme je disais, si tu bosses en communicant bien, y'a 0 conflit lors des pulls et tu peux foncer.

Pendant que tu fatigues tes pauvres doigts avec 2 commandes, le parfait hérisson se contente d'une commande, haha!

[Taro]

Oui, à l’installation il te demande quel comportement tu veux.
Sauf que la personne qui fait l’install n’est pas nécessairement la même que celle qui va utiliser la machine pour développer.

Et les gens qui ne connaissent pas bien Git passent par le pull sans savoir que c’est un ensemble de commandes.
Quand ils ont un problème et que tu veux les dépanner, c’est plus compliqué de savoir ce qui s’est passé.
D’expérience les gens s’en branlent tant qu’ils arrivent à récupérer les commits pour pouvoir pousser les leur...

Même quand tu connais bien Git, je trouve ça naze cette commande.
Je préfère faire le fetch et savoir si les branches ont divergé ou si seul une des deux a des commits supplémentaires.

Parmi les bonnes pratiques qu’on m’a enseignées, il y a celle-là : « pas de pull sinon j’t’aide pas ».
Une autre étant : « tu fais un git status entre chaque commande »
Et si je devais en rajouter une à destination de mes collègues actuels : « vas-y, laisse bien tes merdes en unstaged, et surtout pense à appeler ton entrée du stash ‘tmp pull’, je saurai quoi dire au juge quand on me demandera pourquoi je t’ai coupé en rondelles avant de jeter tes restes au fond du Rhône »

[Anonyme20240202]

cd ..
git clone
cp -r /home/collegue/git_corrompu/mes_changements tmp_git_clone
git add -A; git commit -m "update pour Taro <3"; git push

[Taro]

Jamais ils mettent de <3 les saligauds

[gros_bidule]

Ha ça les branches, une des situations les plus tristes que j'ai vécu c'est lorsque, en SSII, le petit chef de projet voulait que l'on avance sur le sprint actuel + le sprint suivant en même temps, en "avance de phase" comme il se plaisait à dire. Forcément, bossant sur la même base de code, ça donne de sacrés conflits lorsque les trucs faits en avance de phase, mergés dans des feature-branches entre-temps, doivent être mergés dans master. On perdait du temps, surtout les nouveaux qui ne pannaient rien à Git, mais il a toujours persisté dans son idée de prendre de l'avance, malgré le fait que TOUUUUS nos sprints débordaient. On était jamais dans les temps. P'taing, quel débile.

Bizarrement, dans mon nouveau taff, on est plus de 100 personnes sur un ensemble de projets franchement complexes et interconnectés, les chefs sont intelligents, on prend le temps d'être dans les temps (c'est tout un concept ^^) et de planifier les tâches pour éviter les conflits, et les seuls conflits que l'on a sont ultra mineurs, principalement sur des libs partagées par plusieurs projets. En 1 an je n'ai eu qu'un seul conflit, un tout petit de rien du tout. Non mais allô.

[Awake]

C'est très intéressant d'entendre parler de l'intégration continue et peut-être que vous y avez répondu, mais comment faire pour que du travail inachevé ne passe passe pas en prod ? Je pense au web entre autre, par exemple un nouveau bloc d'inscription à une newsletter, l'inté est faite mais ce n'est pas connecté au backend, et pourtant commit sur master. Les tests passent et tout, mais il y a un patch urgent sur master à deployer, et on ne peut pas deploy le bloc newsletter inachevé. Comment ce cas est géré ?

[gros_bidule]

Je dirais tout d'abord que si les tests passent mais que malgré tout le site n'est pas dans un état convenable, c'est que vous ne testez pas assez ou pas bien (pas assez de tests end-to-end ou d'intégration par ex).

Ensuite, vous devriez merger dans master uniquement ce qui fonctionne et est testé (les e2e sont joués et si ça fail, ça bloque le merge). Si le travail est dans un état intermédiaire, mergez plutôt dans feature-branch, que vous mergerez ensuite dans master quand elle sera complète.

Ainsi, master est toujours stable et reflète la prod. D'ailleurs pour le patch en urgence, tu devrais pouvoir l'intégrer sans soucis sur master. Mais vu que ta master n'est plus stable et ne reflète plus la prod, tu es dans le caca.
Une stratégie dans ce cas c'est de garder master = prod, mais tu merges ton boulot dans une branche de preprod ou de dev (comme par ex develop). Tu pousses develop sur master quand tu veux releaser une version (tu en profites pour faire un tag). C'est ce tag que tu mets en prod. Comme ça, si soucis tu remets le précédent patch en prod. Et ton patch en urgence, tu le fais sur le tag qui est en prod. S'il est éprouvé, tu le cherrypick sur master et/ou develop histoire qu'il ne disparaisse pas à la prochaine release.

Aussi, un article que j'apprécie bcp : https://martinfowler.com/articles/br...-patterns.html
La gestion des branches c'est vite compliqué. Il y a de grandes méthodologies plutôt efficaces et complètes, mais aucune ne prend en charge 100% de tes besoins (c'est plutôt 90%), il faut donc choisir celle qui te convient le plus, et faire quelques ajustements pour les cas particuliers, cas qui sont souvent prise de tête.

---

Mais pour en revenir à ton problème de patch en prod, si c'est du one-shot tu peux faire un truc un peu cra-cra : tu crées une branche à partir d'un commit de master qui date d'avant l'intégration du code qui ne va pas. Tu patch et mets cette branche en prod. Ca te laissera le temps de corriger master.
Tu peux aussi revert les commits qui t'embêtent, et tu reverteras ces reverts plus tard , mais là les dieux de Git t'en voudront.

[Dross]

Le principe de GitFlow c’est de faire des longues branches par feature. Une ou plusieurs personnes bossent dans leur coin, quand elles ont fini la branche est mergée dans develop. Ça peut durer un jour comme plusieurs semaines. D’expérience c’est plutôt une semaine en moyenne. C’est un modèle qui favorise les merges de taille assez conséquente.

Le principe de l’intégration continue c’est que tous les développeurs mergent leurs changements dans la même branche (typiquement master ou trunk) tous les jours voire plusieurs fois par jour. Le but est justement d’éviter les gros merges. À chaque merge on valide les changements par un build et des tests. Aujourd’hui on automatise cette partie et cette automatisation est abusivement appelée "intégration continue" puisque c’est le seul truc qu’on peut te vendre. Sauf que ce n’est pas l’automatisation qui rend le code plus robuste, c’est le fait que les participants mettent tous leurs changements en commun fréquemment. Si tu regardes un peu l’historique de cette pratique c’est très clair : à l’époque il n’existait pas d’outil pour automatiser tout ça :D

C’est comme un œuf à la coque. Si tu veux un œuf à la coque c’est 3 minutes dans l’eau bouillante. Si tu le laisses 10 minutes t’as un œuf dur. C’est bon aussi mais c’est pas pareil Pour une branche de dev, moins d’un jour c’est considéré comme "continue". Au-delà ce n’est plus le cas. Mais c’est pas pour autant que ça ne fonctionne pas.

Edit : et l’intégration continue c’est vraiment dur à mettre en place, surtout quand on est habitué à une autre pratique type gitflow. Le principe c’est de changer ta façon de travailler, ça pique un peu C’est d’ailleurs la grosse arnaque des boîtes qui te vendent du CI/CD comme étant une simple case à cocher. Tu te retrouves avec un build continue, rien de plus. C’est déjà bien mais rien ne prouve que cela amènera les bénéfices attribués à l’intégration continue.

C'est comme je disais : faut pas être rigoriste avec tout ça.

Nous on est en mode gitflow quand on a des features par personnes et qui ne se téléscopent pas (ou alors 2-3 entrées dans la solution par exemple), ça ne pose pas de problème vu que de toutes manières les gens ne bossent pas sur la même partie. Et ça a le bon goût de faire des PR propres qu'on peux superviser facilement (cf les juniors).
Si plusieurs devs bossent sur la même partie, alors là on bosse ensemble sur la même branche avec des commits réguliers, pour éviter justement le problème des merges gargantuesques.

Dans tout les cas on a le build et les tests.

Et c'est pas le CI qui rends notre code robuste, c'est notre archi, code et couverture de tests.

[Kamasa]

Puisque ça parle de Git et qu'il semble y avoir des gens pas familier avec les commandes. Voici un p'tit tuto bien foutu
Ca ne parle pas de gestion du dépot git-flow ou pas git-flow, trunk ou goten. Non, c'est juste les commandes.

[William Vaurien]

Franchement les branches de git c'est pas compliqué et ça facilite grandement la vie. (A moins de n'avoir que des branches de R&D avec chacune une base vieille de 6 mois ou plus).

J'ai poussé une équipe de 'vieux dev' qui ne connaissait que CVS à passer sur git (alors que l'équipe d'intégration voulait les faire basculer sur subversion parce que git 'c'est trop compliqué'...).

Le changement s'est fait en douceur, j'ai passé un peu de temps avec eux au début, mais maintenant ils ne peuvent plus s'en passer.

A part pour un dev seul (et encore) je ne vois pas l'intérêt de rester sur un modèle monobranche.

[Taro]

Pareil, même pour mes petits projets perso je bosse couramment avec plusieurs branches.

En gros la branche master compile, tourne, et n'a à priori pas de bugs connus.
A côté de ça les grosses refontes, le "portage" vers une autre plateforme*, etc tout ça ça passe par une petite branche à côté le temps de quelques commits.

*j'écris du code multiplateforme lorsque c'est possible, mais je commence toujours pas développer sur une même plateforme jusqu'à avoir le coeur du truc qui tourne, donc il arrive qu'il y ait quelques fix à faire en visant autre chose.

[Awake]

Merci pour ta réponse @gros_bidule mais du coup si il faut créer une branche dès que le temps de dev de la tâche dépasse quelques heures, je vois pas trop la différence entre trunk based et du flow classique.

[William Vaurien]

Tu ne sais pas toujours si ton dev de quelques heures prévues ne va pas durer plus longtemps...
Avec une branche un dev ne risque jamais de se retrouver "à moitié cuit" sur la branche principale.
Si tu es en équipe et qu'il y a une étape de revue de code, une branche est de toute façon nécessaire.

Et généralement en entreprise tu as un ticket pour le moindre truc, même corriger une coquille dans un label, donc c'est assez simple et limpide de faire ticket -> branche -> pull request -> merge.

Si en plus les outils utilisés s'intègrent dans la chaîne ça donne un ensemble facile à suivre (trouver le ticket du commit et inversement, trouver les tickets d'une release, trouver le commits pour un bug (avec Sentry + intégration Git)...

Le seul truc qui est pénible c'est si tu veux enchaîner plusieurs tickets (pour corriger le bug A, tu veux d'abord faire le refactoring R, et ensuite tu peux dans la foulée corriger le bug B...), en gros quand une branche s'appuie sur une autre.

Après tout seul, ou en équipe restreinte (un dev back-end et un autre front...) ce n'est pas toujours très utile... mais c'est tellement simple que ça ne coûte pas grand chose de prendre l'habitude d'utiliser les branches.

[Awake]

Ouais j'ai déjà bossé de façon classique avec les branches, mais vous avez abordé le trunk based development, et ça m'intéressait parce que comme tu le dis, le flow avec des branches a aussi ses défauts. Je me demandais juste concrètement comment faire dans certains cas comme celui que j'ai décris : du boulot pas terminé, mais qu'il faut commit dans master/main parce qu'il ne faut pas dépasser une journée sans push.

[vectra]

J'aurais plutôt tendance à faire un alias pour qu'un pull fasse apparaître un message indiquant de faire un fetch et ensuite un rebase ou un merge en fonction. Avec insultes en option.

C'est pour un concours de pulls moches?

[Anonyme20240202]

Y'a des branches si tu veux en TBD, c'est juste des short lived branch, souvent appelées "feature branch"

Si t'as un truc à moitié fini tu fais git checkout -b ma_feature, tu mets tes changements dedans, le lendemain tu reviens et tu commit tes changements sous la forme d'une pull/merge request et voilà la branche peut être supprimée et tu as pu sauver tes changements intermédiaires pendant ce laps de temps.

Mais effectivement ce sont juste des conseils généralistes, chacun peut adapter selon ses besoins. Pour moi ce qui compte c'est d'avoir quelque chose d'extrêmement clair et facile d'utilisation.

N'importe quelle personne, même extérieur au projet/domaine doit pouvoir débarquer, faire git clone, cmake, make/make test, faire un changement, git commit.

Perso je commit souvent directement sur le trunk, mais pour les personnes moins expérimentées j'utilise les pull request au début pour pouvoir revoir le commit et adapter si y'a des problèmes.

Quand j'entreprends un truc un peu plus complexe ou que je débarque sur un projet qui ne m'appartient pas je vais aussi faire une pull request généralement pour que ça puisse être revu. Et ça implique de créer une branche temporaire.

Aucune complexité là dedans, y'a ce site un peu verbeux qui en parle, à l'échelle de google même: https://trunkbaseddevelopment.com/

Si des personnes trouvent un intérêt à d'autres type d'orga y'a aucun problème bien sûr. Je pense que le truc important c'est de régulièrement vérifier que tout soit sain.

Combien de fois j'arrive sur un projet et je vois que la moitié des branches sont obsolètes et que les mecs peinent à faire une release et me dire où ils en sont. Enormes merge pas vraiment revus, contenant parfois des trucs de mecs qui sont partis. Une bonne partie des branches qui ne sont même pas testées dans un système (dev, integration, uat, etc.) ou autre type de runtime (tests unitaires etc.).

Le TBD (encore une fois, adapté pour une équipe compact de manière générale) garanti que le code sur lequel tu bosses est du code vivant utilisé tous les jours, et que tout ne fait qu'avancer, même une erreur sur le trunk, ce qui peut tout à fait arriver, des tests parfaits peuvent tout de même inclure un comportement non souhaitable, bah tu le fix avec un commit qui vient s'inscrire linéairement dans l'historique, ce qui est la réalité de la situation. Succession de commit facile à suivre, release notes facile à produire. Et ça requiert un certain niveau d'exigence sur chaque commit, ce qui évite d'avoir un projet qui se délite avec le temps. Y'a pas du code poussiéreux qui s'accumule dans un coin, tout est très clair, explicite, simple. Succession d'incréments intelligibles

Dans le cadre international open source c'est tout à fait normal, mais dans une team compact, avoir 2 personnes ou plus qui travaillent sur la même zone de code sans se synchroniser pendant une periode de temps étendue, généralement c'est un problème.

[William Vaurien]

Ok, donc en fait j'avais pas bien compris le concept du "trunk based dev": c'est à peu de chose ce que nous faisons avec nos branches (il faut être d'accord sur ce qu'est exactement une short lived branch)... Merci d'avoir mis un lien pour que je m'en rende compte !
J'imagine que plus l'équipe est grande plus le temps doit être court, mais il y a sûrement d'autres facteurs à prendre en compte, comme l'age et la taille du projet... Pour notre équipe une semaine est tout à fait acceptable, il n'y aura pas de problème car nous sommes peu nombreux, qu'il y a des spécialistes (plutôt front ou back) et que notre projet principal à passé un cap en terme de maturité, nous touchons rarement aux mêmes fichiers...

[Frypolar]

C'est très intéressant d'entendre parler de l'intégration continue et peut-être que vous y avez répondu, mais comment faire pour que du travail inachevé ne passe passe pas en prod ? Je pense au web entre autre, par exemple un nouveau bloc d'inscription à une newsletter, l'inté est faite mais ce n'est pas connecté au backend, et pourtant commit sur master. Les tests passent et tout, mais il y a un patch urgent sur master à deployer, et on ne peut pas deploy le bloc newsletter inachevé. Comment ce cas est géré ?

Tu utilises des features flags pour que cette fonctionnalité pas totalement finie ne soit pas visible en production. Ça peut aussi permettre de donner accès à cette fonctionnalité à certains clients. C’est très pratique quand ton changement est lié à un retour client. Ça te permet de valider le travail en cours de route au lieu de bosser 6 mois en sous-marin et d’avoir des retours négatifs une fois que c’est fini.

Ensuite, vous devriez merger dans master uniquement ce qui fonctionne et est testé (les e2e sont joués et si ça fail, ça bloque le merge). Si le travail est dans un état intermédiaire, mergez plutôt dans feature-branch, que vous mergerez ensuite dans master quand elle sera complète.

Ce que tu décris est incompatible avec l’intégration continue. C’est pas que ce que tu dis n’est pas bien ou n’est pas une solution valide. Simplement c’est une solution différente de l’intégration continue.

C'est comme je disais : faut pas être rigoriste avec tout ça.

C’est pas une question d’être rigoriste (là on tombe dans l’attaque personnelle ), c’est une question de savoir ce qu’on fait pour connaître les conséquences.

L’intégration continue c’est une pratique (c’est très important) établie par une équipe de développeurs il y a plus de 20 ans. En cherchant à résoudre leurs problèmes, ils ont déterminés qu’en faisant A, B et C ils obtenaient les bénéfices X, Y et Z. Et ceci a été vérifié plusieurs fois dans d’autres contextes, tu as même certaines études sur le sujet. Il est donc établi qu’en faisant A, B et C alors on a les bénéfices X, Y et Z.

Gitflow amène un autre ensemble de pratiques J, K, L. Rien ne dit que J, K, L vont apporter les bénéfices X, Y et Z. Le principe central de l’intégration continue c’est d’éviter les gros merges qui sont sources de grosses instabilités et de temps perdu. D’où la définition :

In software engineering, continuous integration (CI) is the practice of merging all developers' working copies to a shared mainline several times a day.

Là on veut plein de petits changements fréquents pour garantir la stabilité du code dans le temps. Avec gitflow on veut attendre qu’une feature soit terminée avant qu’elle n’arrive dans la branche principale. Les deux sont fondamentalement incompatibles.

Si tu espères obtenir les bénéfices X, Y, Z alors il est important d’être conscient de cette incompatibilité. Si l’intégration continue est utilisée juste en apparence, par exemple pour vendre un produit ou pour faire bien sur un PowerPoint, alors effectivement tu t’en tapes.

Ce n’est pas une question de jugement, c’est une question de définition. D’ailleurs tu pourrais très bien préférer avoir les bénéfices de gitflow plutôt que ceux de l’intégration continue. Le problème c’est que plein d’entreprises font croire que l’intégration continue est facile, accessible à tous et est une question d’outils (à acheter bien sûr) en faisant passer le concept de continuous build pour celui de continuous integration. On se retrouve avec plein de gens qui pensent que l’intégration continue est facile (ce qui est faux et amène généralement à deux soucis) ou que c’est un idéal inatteignable (c’est faux aussi, plein d’équipes y arrivent).

Si tu n’es toujours pas d’accord je t’invite fortement à chercher d’où vient l’intégration continue et quel est le raisonnement derrière en prenant bien soin d’éviter les sites qui cherchent à te vendre une solution toute faite. Même si tu penses déjà connaître le sujet.

[Frypolar]

Ok, donc en fait j'avais pas bien compris le concept du "trunk based dev": c'est à peu de chose ce que nous faisons avec nos branches (il faut être d'accord sur ce qu'est exactement une short lived branch)... Merci d'avoir mis un lien pour que je m'en rende compte !
J'imagine que plus l'équipe est grande plus le temps doit être court, mais il y a sûrement d'autres facteurs à prendre en compte, comme l'age et la taille du projet... Pour notre équipe une semaine est tout à fait acceptable, il n'y aura pas de problème car nous sommes peu nombreux, qu'il y a des spécialistes (plutôt front ou back) et que notre projet principal à passé un cap en terme de maturité, nous touchons rarement aux mêmes fichiers...

Mais j’avais mis le lien plus haut déjà

Une semaine ça n’est plus du TBD/CI. C’est pas que vous faites mal les choses, c’est que c’est différent TBD/CI est avant-tout une gestion du risque. Faire autrement peut très bien fonctionner la plupart du temps ce qui fait qu’on a du mal à comprendre la différence avec d’autres pratiques. Cela devient uniquement visible si tu compares au long terme. Ça saute pas aux yeux immédiatement et ça n’est pas facilement vérifiable.

Cela dit même si tu essaies et que tu réussis, vu que l’avantage principal est l’absence de problème (par exemple un merge problématique nécessitant potentiellement de geler le dépôt pendant x heures/jours ou rendant le build cassé pendant x jours), ben tu ne t’en rends pas compte. Dans mon cas ça fait 2-3 ans qu’on est passé à ce modèle dans mon équipe. J’ai percuté uniquement en écrivant ce message que ça faisait 2-3 ans que je n’avais pas rencontré les problèmes relativement habituels dans le reste de l’entreprise.

[Dross]

C’est pas une question d’être rigoriste (là on tombe dans l’attaque personnelle ), c’est une question de savoir ce qu’on fait pour connaître les conséquences.

L’intégration continue c’est une pratique (c’est très important) établie par une équipe de développeurs il y a plus de 20 ans. En cherchant à résoudre leurs problèmes, ils ont déterminés qu’en faisant A, B et C ils obtenaient les bénéfices X, Y et Z. Et ceci a été vérifié plusieurs fois dans d’autres contextes, tu as même certaines études sur le sujet. Il est donc établi qu’en faisant A, B et C alors on a les bénéfices X, Y et Z.

Gitflow amène un autre ensemble de pratiques J, K, L. Rien ne dit que J, K, L vont apporter les bénéfices X, Y et Z. Le principe central de l’intégration continue c’est d’éviter les gros merges qui sont sources de grosses instabilités et de temps perdu. D’où la définition :



Là on veut plein de petits changements fréquents pour garantir la stabilité du code dans le temps. Avec gitflow on veut attendre qu’une feature soit terminée avant qu’elle n’arrive dans la branche principale. Les deux sont fondamentalement incompatibles.

Si tu espères obtenir les bénéfices X, Y, Z alors il est important d’être conscient de cette incompatibilité. Si l’intégration continue est utilisée juste en apparence, par exemple pour vendre un produit ou pour faire bien sur un PowerPoint, alors effectivement tu t’en tapes.

Ce n’est pas une question de jugement, c’est une question de définition. D’ailleurs tu pourrais très bien préférer avoir les bénéfices de gitflow plutôt que ceux de l’intégration continue. Le problème c’est que plein d’entreprises font croire que l’intégration continue est facile, accessible à tous et est une question d’outils (à acheter bien sûr) en faisant passer le concept de continuous build pour celui de continuous integration. On se retrouve avec plein de gens qui pensent que l’intégration continue est facile (ce qui est faux et amène généralement à deux soucis) ou que c’est un idéal inatteignable (c’est faux aussi, plein d’équipes y arrivent).

Si tu n’es toujours pas d’accord je t’invite fortement à chercher d’où vient l’intégration continue et quel est le raisonnement derrière en prenant bien soin d’éviter les sites qui cherchent à te vendre une solution toute faite. Même si tu penses déjà connaître le sujet.

Il se trouve que justement, j'avais lu sur le sujet. Et cette pratique était arrivée quand des gens travaillaient avec d'autres outils (pas les IDE d'aujourd'hui) et d'autres pratiques (pas des petites classes à portée limitée, injection de dépendance, inversion de contrôle et tout le toutin : du moins pas dans les proportions d'aujourd'hui, les builds étaient aussi infiniment plus long, ce qui pouvais amener des avantages à merger tout ensemble plus rapidement (dans un des exemples antédiluviens du CI ils parlaient de builds de 6h de mémoire)).

C'est en cela que je dis qu'il ne faut pas être rigoriste (c'est pas une insulte), et vouloir coller au canon car c'était le canon de l'époque. L'époque à changé, les pratiques et les outils aussi. Ce qu'il faut retenir c'est leur enseignement, et c'est : il ne faut pas que deux branches divergent sur le même codebase trop longtemps, quelques heures au pire. Mais faut déjà que deux dev bossent sur le même code pour que ça arrive. Franchement chez nous c'est rare, et quand ça arrive c'est pas grave, soit tu pull stratégiquement les modifs de l'autre quand y'a besoin, soit tu bosse sur la même branche exceptionnellement.

Et j'en suis d'autant plus conscient qu'on a appris ça à la dure : quand je suis arrivé dans ma start-up on était 2 (moi compris), on avais rien, pas même de branches. Quand on a commencé à les mettre en place on s'est inspirés des pratiques MS et on a malheureusement laissé divergé les branches pendant des semaines voir des mois (on était en waterfall et pas en agile à l'époque). On a souffert, beaucoup. Et on a appris. Aujourd'hui on n'a plus de problèmes.

Et on a tout les avantages liés au CICD. Tous sans exception.

Mais je le redis : dans ce domaine y'a rien de canonique, ce qui marche chez nous ne marchera pas forcément ailleurs. Faut comprendre ce qui fait l'attrait de la méthode et l'adapter pour en avoir les avantages dans votre équipe. Tant que vous obtenez les avantages, on s'en fout que y'a 20 ans ils faisaient autrement.

[ook4mi]

Question naïve : je ne suis pas dev, je l'ai été brievement dans ma précédente boite mais sans entretien avec le client... J'aimerais rebasculer côté technique et je me suis lancé dans le défi 100days of code

Je m'amuse de plus en plus avec Python et j'aimerais me créer une vitrine, je pensais utiliser github mais avoir 2 comptes :
1) pour la vie de tous les jours -> pour rien perdre et faire des erreurs
2) pour quand c'est stable/propre/interressant à montrer -> vitrine

Est-ce une bonne pratique ou à l'inverse : cela ne sert à rien car une vitrine personne n'y va ? Ou il n'est pas grave de push même si il y a encore des anomalies tant qu'à la fin d'un "projet vitrine" le résultat est bon ? Sachant que forcément la vitrine aura un push tous les X jours, l'autre sera surement beaucoup plus actif.

Merci pour le partage du guide sur Git

[Anonyme20240202]

Je suis sûr la même trajectoire et je pense qu'au final le mieux est de n'avoir qu'un seul compte.

Une fois qu'un projet est fini ou présentable tu peux officialiser la chose avec un readme bien propre ou une page github https://docs.github.com/en/pages/get...hub-pages-site

ou un wiki github. Et tu peux accompagner ça d'une vidéo (genre dans le cas de calculs graphiques lourd c'est très commun) ou n'importe quoi d'autre qui permet de présenter le projet de manière simple, un site web avec une API vers ton app, etc.

Et concernant tous les projets "moches" "en chantier". Bah c'est pas grave, ils sont dans ton repo mais ça montre tes centres d'intérêt, y'a aucun mal à ça. Je pense que c'est plus pratique que d'alterner et transvaser les trucs entre 2 comptes. Tu peux mettre un gros WIP dans le readme au début. Il ne peut t'arriver que des bonnes choses en étant ouvert, quelqu'un qui vient t'aider, un mec qui voit que tu partages certains centre d'intérêts, etc.

Et si jamais tu contribues à un project existant, c'est aussi positif et c'est sur le même compte

[Dross]

Github propose aussi des repos privés gratuitement maintenant, c'est pratique pour les WIP qui n'ont pas pour but d'être publiés, ou des tests abandonnés, ou des débuts de projets que vous voulez garder secret au départ (vos plans pour prendre le contrôle du monde en général).

Ça permet de garder un listing plus propre. Et de toutes manières sur ton profil tu épinglera les repos que tu aime le plus, veux mettre de l'avant.

[Anonyme20240202]

Exemple de projets au pif qui utilise github comme vitrine

Librairie de logs
https://github.com/gabime/spdlog avec un beau readme, et un wiki sur github: https://github.com/gabime/spdlog/wiki/1.-QuickStart

Un blog/projet qui se suffit à lui même en temps que vitrine (il parle des nouveautés en c++20): https://oleksandrkvl.github.io/2021/...-overview.html