Reprise du message précédent :
C'est dingue https://youtu.be/IlrMkHaCosw

 
Le dernier a un faux air de Depardieu sobre.

L'original aussi

dites, on développe des features à plusieurs dev sur notre appli et j'ai demandé àce qu'on fasse une branche par ticket de la feature.
 
En gros, on a une grosse feature, et on a plusieurs tickets jiras de créé pour cette feature, et pour chaque ticket qui doit être développé, je demande à ce qu'une branche soit créée.
Mais ensuite, j'ai besoin que les devs atterissent dans une branche temporaire, sans avoir à pourrir dévelop qui est en standby car une autre release est en cours sur la branche develop.
 
Du coup on se retrouve avec des branches type :  
 
feature/myfeat/main (branche principale ou tout atteri après pull request)
feature/myfeat/FEAT-1234-titre-du-ticket
feature/myfeat/FEAT-4566-titre-du-ticket2
 
FEAT-1234 est le code du ticket jira, ça peut-être HARK-6666.
 
Et main est la branche ou tout atterri et ensuite cette branche sera mergée via PR dans develop quand tous les pairtest auront été validés.

Y a une question ?
 
Mes équipes font comme ça depuis 10 ans

Ya une technique pour éviter le vieux code qui revient lors d'un merge au fait ? (quand master/develop a reçu un patch mais qu'on le perd lors d'un merge ultérieur avec une branche plus vieille)

ben celui qui soumet la feature doit avoir testé le merge et se palucher les différences ?
Je vois pas comment ton modèle peut marcher si chaque owner de branche s'assure pas que sa branch est mergeable avec la HEAD du trunk
 
C'est la procédure ici : tu peux rien soumettre si un merge avec HEAD genère un conflit. Et oui si le trunk est dynamique ça peut etre relou (là il faut un peu de coordination humaine pour séquencer le truc)

+1

On avait le problème avec les PRs mergées en maintenance puis régulièrement quelqu'un allait merger les branches de maintenance vers les plus récentes (à coup de git merge) e.g. t'as les banches v1, v2, v3, v4 et la master, tu peux avoir des trucs qui vont être mergés en v2 puis régulièrement (ou irrégulièrement) quelqu'un va aller merger v1 dans v2, v2 dans v3, v3 dans v4 et v4 dans master.

Le problème c'est qu'avec les divergences dans les branches (surtout si il y a pas mal de temps e.g. releases annuelles ou quoi) et l'activité de maintenance sur les vielles branches, la personne qui fait le merge va nécessairement se taper des conflits plus ou moins gros, et va rater des trucs, et ça prend un temps dingue. Et cette personne ne peut pas aller demander aux auteurs parce-que git lui file un gros paquet de merde avec des conflits au milieu et "demerden sie sich" (pas qu'il puisse nécessairement mieux faire, en tout cas avec son modèle de révisions "snapshot" ).

Et tu peux pas aller merger dans tous les sens dès qu'un truc est poussé dans une branche basse, ça te crée un histo qui ressemble strictement à rien.

Donc on est passés à des backports/forward ports, un peu comme dans python (chez nous on fait des forward ports mais ça marche dans les deux sens): tu merge un truc, du dis sur quelle range de branche il faut l'intégrer, et ça te crée des "sous-PR" pour chacune des branches concernées. Comme ça la gestion des conflits est distribuée et surtout c'est le dev qui a fait le changement initial qui va le fixer (ou refaire, ou dropper selon la quantité de churn).

Le seul truc chiant c'est que quand tu log / blame t'as plus un lien direct vers le commit d'origine, donc faut parfois se ballader un peu pour retrouver.

en fait ouais, en terme de nom de branche et orga, est-ce bon d'avoir une branche feature/XXXXX/main, ou un autre nom serait mieux ?

Ah, osef du nommage tant que les gens s'y retrouvent.  
Donc mettez-vous d'accord sur une convention (ou pas) et roule.

Il y a des gens qui utilisent des macro keyboards ou des pads midis pour se faire des raccourcis icite? Que ce soit pour le dev, pour des raccourcis autres (genre media) ou pour gérer leur onlyfans.

C'est mergeable sans conflits évidemment, sinon le problème serait simple "résout le confit proprement et c'est bon".

En général c'est ce genre de scénario :
1. quelqu'un crée une branche pour faire de l'exploratoire (mise au point d'algos ou de méthode, le genre de trucs qui peut prendre quelques semaines ou mois)
2. la branche est régulièrement mise à jour avec la branche principale pour ne pas trop diverger, mais à un moment peut-être qu'un merge a été mal fait (par ex : mauvais choix lors de la résolution du conflit)
3. plus tard (et après plusieurs merges heureux pour rester à jour vis à vis de la branche principale), les derniers nettoyages ont lieu, et c'est le moment de récupérer la feature
4. merge sans soucis dans master/develop, sauf que... le pb qui a eu lieu en #2 quelques semaines avant vient de silencieusement écraser la bonne version du code.

I feel judged

 
C'est pas mal comme approche, intéressant.

Je juge pas une seule seconde

Franchement pour l'instant ça marche bien, c'est ultra plus fiable que les gros merge de synchro, ça responsabilise les devs, ça distribue l'effort, …

Le CI en prend plein la gueule par contre On a 8 branches "live" actuellement, donc une PR mergée dans la plus ancienne va créer 7 PRs et les builds qui vont avec si il y a pas de conflits, puis les stagings qui correspondent

 
Ya vraiment pas mal d'avantages à faire plusieurs merges dans différentes branches plutôt que de miser sur un truc séquentiel en fait...
 
Par exemple pour éviter les problèmes de merge liés aux cherry pick, au lieu de faire un commit dans une branche puis de le cherry-pick dans une autre tu peux le placer dans une troisième branche qui part de 'base' (du point de divergence en gros) et faire deux merges, un dans chacune des branches. Du coup tu as bien ton commit aux deux endroits mais tu as aussi la garantie d'éviter les problèmes 'silencieux' lors du merge de ces branches plus tard.

Si je comprend bien, tu veux dire que tu fais une branche de dev et tu fais une PR pour chaque branche officielle? Ça marque que pour la direction "forward" donc c'est une limitation, tu vas rien gagner quand tu vas avoir des conflits (genre PR sur branche 1, merge ok dans 2 et 3, mais 4 a changé donc t'as un conflit sur celle là, comment tu résoud? Si tu fais une nouvelle branche à la place tu split ton effort comme avec des cherrypick, sauf que ça devient une exception donc les gens vont moins s'y attendre), et tu vas quand même avoir un histo (à mon sens) dégueu à cause de merges entre des branches super divergentes.

Je parle de l'approche "Stop cherry-picking, start merging" de Raymond Chen ici https://devblogs.microsoft.com/oldn [...] 0/?p=98235  (btw pas de notion de PR ici c'est du git pure, sans gitlab/github)

C'est plus ou moins ce dont je parle, c'est pas un problème quand t'as 3 commits de divergence, quand t'en a 3000 je suis moins persuadé (et c'est pas un nombre exagéré, entre notre master et la plus ancienne branche encore maintenue on a pas loin de 20000 commits).

Mais avec 3k à 20k commits de divergence la branche vit sa vit dans son coin non ? Tu vas quand-même tenter des merges pour récupérer ses fix spécifiques alors que le code est si différent  

Oui? On parle toujours d'appliquer des changements sur des branches multiples là non?

On fait plus de merges entre les branches de référence j'ai dit
 
Mais par défaut les changements dans une branche sont portés sur toutes les branches qui suivent, donc oui.
 
C'est une grosse base de code mais tout ne change pas nécessairement à la même vitesse, des fois quand on blame on retrouve des morceaux qui ont pas changé depuis 2006

 
je comprends pas comment 4. arrive, parce que au moment du merge le code #2 va apparaitre comme un diff, et donc tu vas bien voir qu'il y a une différence, non ? Et puisque ta branche vient d'un head plus vieux, ça doit apparaitre en tant que conflit, non ?
 

Tu verras une différence oui, mais pas un conflit non. En 2 le code a été merged et le conflit déjà résolu (mais en adoptant la mauvaise solution hélas). Et si c'est une différence parmi beaucoup il faut des tests de régressions pour détecter qu'un bout de code est revenu en arrière..

Si j'essaie de donner des exemples venant de cas réels ça donnerait ça :
1. une branche feature part de master pour mettre au point l'algo. Puis master évolue et corrige un bout de code proprement, pendant que feature corrige le même code salement pour pouvoir avancer.
2. lors d'un merge de master dans feature sur un conflit on fait mal le boulot et on garde la version de feature (hélas).
3. désormais chaque merge de master dans feature se passe bien, car on n'incorpore que les nouveautés depuis le dernier merge point (on ne revient pas sur les conflits déjà résolus)
4. après moulte nettoyage on est prêt, on met feature dans master, pas de conflit non plus, le correctif malheureux est vu comme une nouveauté de feature à garder. Un œil attentif verra bien le changement dans le diff du merge, mais de là à percuter qu'on est en train de restaurer un vieux truc et que la modification n'est pas légitime...

Ici on paie cher le merge malheureux (#2) qui a peut-être eu lieu 3 mois plus tôt. C'est un problème de temporalité en fait un chercheur va mettre du temps pour explorer et mettre au point ses méthodes, il peut incorporer régulièrement master chez lui pour rester à jour, mais au moment du merge final ça sera toujours problématique de ne pas avoir pu intégrer la chose progressivement, par petites touches. Trop de code à revoir.

Un scénario un peu différent mais qui aboutit aussi à un merge problématique et sans conflit :
1. un bug est trouvé dans feature, on fait un patch rapide pour le contourner (par ex un 'if' pour shunter le truc)
2. on report de correctif dans master faute de mieux pour le moment
3. plus tard on fait le vrai correctif dans feature, on retire de 'if' malheureux et on corrige le pb en profondeur

Au moment du merge que voit git ?
- dans base : pas de if
- dans master : un 'if' de contournement
- dans feature : pas de if (mais le vrai fix ailleurs)
git garde le 'if' et le vrai fix, qui sont les nouveautés de chaque branche.

git lors d'un merge ne regarde que les sommets des deux branches (et pas les commits un par un, sans quoi il aurait vu un ajout de 'if' concomitant puis sa suppression plus tard) VS le dernier point de divergence (la base), il n'est pas plus intelligent que ça, ce qui s'est passé 3 merges plus haut ne compte pas, remonter au tout premier point de divergence non plus.

elles font quelle taille tes branches ?  
 
Le problème qu'il peut y avoir ici c'est la taille des commit : si tu dois merger 10kloc, tu verras jamais les régressions c'est sur.
Pour le point 1/ si tu corriges un bug upstream (ce que fait feature en corrigeant un bug du trunk), à mon sens ce fix devrait etre sa propre branche. 2 bénefices : tu peux continuer à avancer sur feature en patchant feature avec ta bugfix branch, et en soumettant bugfix branch, il va se passer une des deux choses :  
- tu soumets avant le bugfix du master, et quand le master soumet le patch propre ça va péter
- tu soumets le fix après master, et ça va péter à ce moment là
 
t'as intéret à réduire la durée de vie des features branchs, en mergeant souvent avec le trunk en ayant des feature flags, sinon c'est trop le merdier si vous etes beaucoup à toucher le meme code avec des semaines entières sans merge.
 
Si je compare par rapport à ce qui se fait ici :  
- tu es encouragé à faire des change court (<1kloc), si tu le fais pas le reviewer peut te demander de découper ton change
- tu es encouragé à soumettre le plus souvent possible, même un truc partiel tant que tu casses pas le fonctionnement actuel, et tant que ton code compile et est vivant (au moins exercé par des tests), pas le droit de soumettre du code commenté. Faudrait demander à Hepha qui a une vue plus large que moi, mais de ce que j'ai vu dans l'équipe les gens soumettent au pire 1x par semaine, en pratique plus fréquemment
- on travaille tous sur des branches qu'on peut se patcher entre nous, mais c'est celui qui submitte qui doit s'assurer du merge valide
- si tu casses, tu fixes. (ce qui crée une incitation à pas laisser une branche ouverte 100 ans, parce que sinon quand tu merges c'est bagdad, et c'est ton problème)
 
du coup ton example serait hyper rare parce que les changes sont trop petits pour que ça arrive, et la courte durée de vie des branches limite le chevauchement temporel.
Ça veut pas dire que t'as pas la malchance de voir tout ton code pourrir parce que qqn vient de soumettre du code qui change des trucs juste avant toi, mais c'est le jeu ma pauvre Lucette : si tu arrives en deuxieme, tu fixes

C'est pas 10kloc quand-même mais ça peut être éparpillé sur beaucoup de fichiers. Pour le fix dans sa propre branche (et merge pour l'avoir chez soi) je suis complètement d'accord.

Après c'est pas évident pour le merge fréquent, je me tâte encore car ça pourrait limiter la casse et c'est sûr que c'est un gros avantage, mais le code peut aussi être jeté si la méthode ne donne rien au final et on aura demandé revue de code et couverture par des tests pour rien du coup.

Je note le «au pire 1x par semaine dans le trunk» en tout cas, comme référence.

 
Je vois pas de façon d'éviter ça. C'est par ailleurs vrai pour tout code, tu peux pas toujours prédire combien de temps ça va vivre, ni quel essai va marcher.

Ils ont dépensé sans compter

 
C'est... gros.

Moi aussi j'ai un PC avec 16,0000000 cœurs et 16,000000 GiB de RAM Pourquoi ils mettent autant de chiffres après la virgule hein
 

C’est pour les gens comme much qui pensent faire une affaire en achetant  

Purée, qu'on adopte enfin une notation avec des séparateurs standards (et la date en inversé)

ça a du engendrer une petite économie...

 
 
Existerait-il un outil simplifié de gestion de base de données mysql pour utilisateurs lambda ?
Plutôt que de créer un système de CRUD afin que le client puisse valider/modifier/supprimer des entrées provenant d'un site web je me disais qu'une version limitée et modifiée de phpMyadmin serait vraiment top...  
Quelque chose qui soit même éventuellement paramétrable pour éviter l'accès a certaines tables/colonnes...

Navicat ? Mais pas sûr que ce soit noob-friendly

 
Admin autogénérée de certains framework ? Genre Django, ça te fait du CRUD de base avec au final assez peu de ligne de code, le plus long est probablement le fait de générer la description de tes modèles (mais me semble que pour le cas de django t'as un outil maintenant où tu peux faire de l'instrospection d'une BDD existante)

 
Ben t'as toujours des clients lourds pour les databases, plus ou moins intuitifs.