Discussion :

[pcouas]

Bonjour

L’équipe que je viens d’intégrer fonctionne avec des branches de « release » parallèles issues du « master » mais qui vont en prod à des dates différentes. Le rapatriement des commits de certains développements de ces branches pose souci. Le but étant de ne pas perdre de commit et de garder le hash.

Ex master :

1 On crée une branche release "RAout2024" depuis "master" puis une branche release "ROctobrre2024" depuis "master"
2 Un DEVELOPPEUR1 crée une feature "HelloWorld" depuis "RAout2024" puis après le développement MergeResquest sur celle ci
3 (En meme temps pour faire simple)Un DEVELOPPEUR2 crée une feature "Welcome" depuis "ROctobre2024" puis après le développement MergeResquest sur celle ci ( "ROctobre2024" )
4 On souhaite
- A Récupérer avec les mêmes numéro de hash la feature "Welcome" sur la branche "RAout2024" et "master".
- B On souhaite également vérifier qu'il n'y a pas de dev qui sont sur "RAout2024" et qui ne serait pas sur "ROctobre2024"

Actuellement ce sont des commits. Le rebase serait-t-il mieux ?

[Obsidian]

Bonjour,

C'est un problème assez courant, dû en réalité à un modèle inadapté. J'ai moi-même essayé de le suivre avant de converger vers les Linux Kernel Guidelines et de les adopter pour mes propres projets.

4 On souhaite
- A Récupérer avec les mêmes numéro de hash la feature "Welcome" sur la branche "RAout2024" et "master".

Il n'est pas possible d'avoir deux commits (fussent leurs contenus identiques) portant le même hash puisque c'est ce hash et lui seul qui permet d'identifier un commit parmi la collection entière d'un dépôt et de le retrouver. Par ailleurs, le hash est la somme SHA1 du contenu d'un objet Git, dont les commits font partie, ce qui les rend immuables par nature. Si tu altères même légèrement un commit, par exemple en l'amendant pour modifier son message sans toucher à son contenu, alors il sera dans tous les cas remplacé par un nouveau commit identifié par un hash différent.

D'autre part, les branches, sous Git, ne sont pas des objets à part entière sur lesquelles on viendrait placer ses commits : chaque commit référence en fait lui-même le précédent (ou les précédents dans le cas d'une fusion) et cette référence fait partie de la charge utile du commit. Ce sont ces inter-références qui forment l'historique de tout un dépôt, une branche étant alors une sous-partie de cet historique, identifiée par une étiquette que l'on place à son sommet (le dernier commit en date) et que l'on déplace au fur et à mesure qu'on y ajoute de nouvelles contributions. Donc, lorsque tu références un commit donné, tu retrouves non seulement son contenu mais toute sa descendance.

D'un point de vue théorique, il faudrait en fait « fusionner » le commit concerné à l'aide d'une merge request comme tu le fais pour les sous-branches des développeurs à chaque feature. Tu établirais ainsi une référence directe vers le commit en question. Mais non seulement le graphe deviendrait épouvantable à lire, mais tu intégrerais également le reste de la branche release qui le porte dans celle de destination. Donc inapplicable ici.

Tu peux par contre « rejouer » les modifications introduites par un commit donné à l'aide de git cherry-pick. Ceci introduit un nouveau commit appliquant exactement les mêmes modifications que le commit de référence et seulement lui (indépendamment de la branche à laquelle il appartient), mais évidemment avec une somme propre. Si tu veux conserver la trace du commit original (qui, lui, continue d'exister sur sa branche), tu peux la déposer dans le message associé à l'intention des développeurs, même si git lui-même n'en aura aucune conscience. Tu peux même utiliser l'option -x pour le faire automatiquement et, ainsi, être sûr de ne pas te tromper.

- B On souhaite également vérifier qu'il n'y a pas de dev qui sont sur "RAout2024" et qui ne serait pas sur "ROctobre2024"

Tu touches du doigt la cause de tous tes problèmes actuels : tu es en réalité en train de maintenir deux branches identiques en parallèle. Exactement comme on le fait dans une base de données, s'il s'agit d'un même contenu, alors celui-ci ne doit jamais exister en double (sauf redondances volontaires pour la tolérance aux pannes et qui, dans ce cas, est assurée par d'autres biais). Et cela va empirer à chaque nouvelle release : il faudra alors maintenir rétroactivement les évolutions en triple, puis quadruple, etc.

Actuellement ce sont des commits. Le rebase serait-t-il mieux ?

Rebase, comme son nom l'indique, sert à « rebaser » une branche, c'est-à-dire la « débrancher » de son point d'implantation et la rebrancher ailleurs. C'est utile, par exemple, lorsque le développement d'une feature sur une branche dédiée prend un peu trop de temps et que le tronc principal a trop évolué entretemps. Sous Git, cela fonctionne en rejouant chaque commit de la branche vers le nouvel emplacement (comme une multitude de cherry-picks successifs) et en déplaçant l'étiquette. Donc, en réalité, on reconstruit la branche à partir du nouvel emplacement.

Tu peux utiliser rebase pour « copier » une branche, mais pour résoudre le fond du problème, je te conseille plutôt (si c'est possible dans ton équipe) d'adopter les mêmes règles que celles qui ont actuellement cours dans le noyau Linux :

1. Les noyaux officiels sont tous issus de la branche de Linus Torvalds du dépôt Git du développement du kernel (soit /pub/scm/linux/kernel/git/torvalds/linux.git). À l'heure où ce message est écrit, le prochain noyau à sortir sera le 6.11, le suivant sera le 6.12, etc.
   
   
2. Les branches dites « stables » émanent toutes d'un noyau officiel déjà sorti (c'est important). Dès la parution du 6.11, par exemple, une branche stable qui lui est dédiée est ouverte et accueille les noyaux 6.11.1, 6.11.2, 6.11.3, etc. Toutes les branches stables peuvent continuer à exister indéfiniment même si d'autres noyaux sortent entretemps. Il y a cependant un horizon (que je n'ai plus en mémoire), qui est prolongé pour les versions LTS ;
   
   
3. La politique concernant les noyaux stables est « correctifs ou mises à jour uniquement. Pas de nouvelles features. »
   
   
4. Et surtout le point numéro 1 de cette politique : le patch à intégrer (ou un patch équivalent) doit déjà exister dans la lignée principale. Cela signifie que c'est d'abord la branche principale qui est mise à jour et que le correctif est ensuite rétroporté vers les branches stables, lesquelles jouent alors bien leur rôle : « arrêter » une version donnée du noyau et l'affiner avec le temps.

En ce qui concerne la branche principale à présent :

• Toutes les fonctionnalités à intégrer dans le noyau font l'objet de branches dédiées par les équipes de chaque sous-système, transmises d'abord aux mainteneurs de ces sous-systèmes, lesquels les relaient à Linus Torvals lui-même, lequel les intègre finalement dans le tronc principal. Donc la branche master ne contient en fait que des merge requests ou presque ;
• Pour chaque nouvelle version, une fenêtre d'intégration (merge window) est ouverte pour intégrer toutes ces branches. Elle l'est immédiatement après la publication du noyau précédent et dure en principe exactement deux semaines. Cela signifie que tous les développement menés à un moment t ne sont jamais intégrés dans le noyau à paraître, mais au mieux dans le suivant.
• À l'issue de cette période, la fenêtre est refermée et le noyau ainsi formé constitue la première release candidate du noyau à paraître, donc « -rc1 ». Si tout fonctionnait sans aucun problème du premier coup, elle sortirait directement en l'état mais on sait que ce n'est jamais le cas. Chaque release candidate est soumise à une période d'examen d'exactement une semaine, et quand l'une d'entre elles est jugée satisfaisante par tous, le nouveau noyau est publié en l'état.

Ce qui est intéressant ici, c'est que l'on stabilise d'abord la branche principale avant de se soucier du reste. Quand on ouvre une branche « release » trop tôt, on se retrouve à porter systématiquement les correctifs que l'on y apporte vers la branche principale, alors même que celle-ci continuer d'évoluer. Par ailleurs, et de manière complètement empirique, même en étant généralement seul à travailler sur un de mes projets, je constate que je converge vers le même nombre de release candidates, soit en moyenne sept versions avant d'atteindre la bonne.

[pcouas]

Bonjour

Je n'ai malheureusement pas le pouvoir de faire changer les process de ce client et des équipes en place.
Actuellement j'ai un soucis avec le bouton "rebase" de la UI de gitlab qui n'apparait pas
* J'ai la branche Octobre2024 et la branche de Decembre2024
* un MR entre ces deux branches
* Mon projet permet un Fast Forward Merge
Mais après avoir push des changements differents sur la branche Octobre2024 et la branche Decembre2024, je ne vois pas le bouton "rebase" sur ma MR
Ou est mon erreur ?
Merci