Bonjour à toutes et à tous,
Je développe, généralement seul, une librairie gtk-fortran que je "push" sur GitHub. Il y a deux branches principales et bientôt trois : gtk2, gtk3 et gtk4. La branche gtk2 n'est plus maintenue, la branche gtk3 continuera à être maintenue quelques années après la création de la branche gtk4, qui au départ sera expérimentale :
0----------------------------------------------gtk2----|
\
\-----------------------gtk3-------------------...
\
\-----gtk4-------------------------------------...
Ces trois branches principales correspondant à trois versions de la librairie GTK sont destinées à ne jamais fusionner. Mais il peut m'arriver d'ajouter ou de corriger quelque chose dans gtk3 et de vouloir l'importer dans gtk4, ou réciproquement de rétro-porter quelque chose de gtk4 vers gtk3.
Jusqu'à maintenant, j'ai généralement utilisé git cherry-pick qui permet de copier un ou plusieurs commits d'une branche vers une autre.
Y a-t'il d'autres façons de faire ? J'ai pensé à créer une sous-branche puis à utiliser git merge ou git rebase, mais fusionner une sous-branche avec une autre branche principale ne semble pas avoir de sens. Et faire un git rebase au bout de deux branches principales ne me semble pas possible non plus puisque qu'après le premier "rebase" la sous-branche n'existera plus en tant que telle, si j'ai bien compris.
Autre question : un git rebase est-il parfaitement équivalent à une série de git cherry-pick ?
Merci d'avance
# Une seule branche avec des options de compilation
Posté par benja . Évalué à 5.
Autant essayer de tout avoir dans une seule branche. Les modifications au code commun n'auront pas à être fusionnées (cherry-pickées), le code séparé est considéré "optionel" (i.e. ./configure --enable-gtk5), et est soit entouré de #defines et/ou dans des fichiers ou dossiers séparés. Les branches te servent uniquement au release management: grosso modo des branches de feature, une de dévelopement dans laquelle les précédentes sont fusionnées, et une ou plusieurs branches de versions stabilisées. À mon avis c'est le moins prise de tête (imagine d'avoir une branche dev pour gtk3, pour gtk4, et puis par feature, etc. ça va vite être ingérable tant pour toi que pour git…).
[^] # Re: Une seule branche avec des options de compilation
Posté par 16aR . Évalué à 2. Dernière modification le 19 février 2020 à 09:52.
Je suis d’accord. Autant, avoir des branches de release pour ton propre logiciel sur des versions maintenues en parallèle fait sens : v19 et v13 par example.
Par contre, avoir des branches par version majeure de dépendances, je pense que ça a plus de désavantage qu’autre chose.
Dans ce cas, tu as juste une dépendance vers gtk, donc ça va. Imagine tu aurais en plus des dépendances vers une lib audio + une autre. Tu ferais la combinaison de chaque dépendance dans une branche dédiée ? gtk3-pulseaudiov13, gtk3-pulseaudiov12, gtk4-pulseaudiov13, gtk4-pulseaudiov12, gtk3-jackv1, gtk3-jackv2, …
Du coup, si ton code est bien organisé, tu peux modifier une partie du code sans toucher au gtk et ça marchera bien sur toutes les versions des dépendances.
Et vice versa, si tu dois modifier une logique uniquement liée à gtk4, seule la partie gtk4 sera modifiée.
Je pense qu’un bon design de ton code devrait permettre cela, et les branches longues git ne serait que pour versionner ton code, pas celui des dépendances.
[^] # Re: Une seule branche avec des options de compilation
Posté par vmagnin (site web personnel) . Évalué à 1.
Tout d'abord, merci pour vos avis à tous les deux. Ca alimentera ma réflexion !
En fait, dans ce projet, GTK est plus qu'une dépendance puisque gtk-fortran est une interface entre le langage Fortran et GTK. Le système de build et le wrapper qui crée les fichiers contenant les quelques 10000 interfaces Fortran/C sont indépendants de la version de GTK. Mais ces fichiers contenant les interfaces, ainsi que les exemples de programmes contenus dans le projet, sont très dépendants de la version majeure de GTK : quand on passe de GTK 2 à GTK 3 et bientôt GTK 4, il y a énormément de fonctions qui apparaissent, disparaissent ou sont modifiées, et la philosophie globale de la librairie est modifiée.
[^] # Re: Une seule branche avec des options de compilation
Posté par benja . Évalué à 1. Dernière modification le 22 février 2020 à 11:45.
Bravo à ton équipe et à toi pour cet excellent boulot. Encore quelques pistes:
pourquoi inclure du code généré dans le tree? traditionnellement on fait une sorte de "make dist" qui va générer tous le fichiers nécessaires à la distribution d'un tarball source.
si le code conflictuel est uniquement issu des fichiers générés, ne les générez plus… :) ou bien uniquement dans des branches dédiées.
n'est-il vraiment pas possible de fusionner le tout après une certaine réorganisation ? Ce qui est dans /example devient example/gtk2, /src/ -> /src/gtk2, ce qui est commun ou qui peut facilmenent le devenir (mode de compilation et/ou #define) va dans /src/common. Le coeur de génération a déjà l'air d'être commun ce qui est une très bonne chose. J'imagine que le gros du travail sera de fusionner les fichiers cmake/meson. Il suffirait à mon sens de générer une (sous-)librairies par version de gtk, rien d'impossible AMHA.
si vraiment vous souhaitez garder des branches, avoir une telle séparation au niveau des noms des répertoires et fichiers simplifiera grandement les différents merges. Par exemple: vous développez src/cfwrapper dans sa propre branche que vous fusionnez régulièrement dans les branches gtk2,3 (et 4)…. Mais encore une fois, celà me semble une approche compliquée.
git-filter-branch/filer-repo peut aider à faire ce genre de réorganisation en gardant l'historique.
[^] # Re: Une seule branche avec des options de compilation
Posté par vmagnin (site web personnel) . Évalué à 1.
Merci pour votre réponse. Je vais réfléchir à tout ça.
Le projet a débuté en janvier 2011. Je n'avais alors jamais utilisé un outil comme git. Chacun a apporté ses compétences, le projet a plutôt fonctionné en mode auto-organisation et il a pris plus d'ampleur qu'imaginé au départ. L'automatisation de la création des interfaces C/Fortran par un script Python a fait explosé le compteur ! Il traîne donc des casseroles historiques. J'ai fait pas mal de ménage récemment au niveau des différents codes. Mais il faut effectivement que je réfléchisse à l'organisation du dépôt. D'où mon post dans ce forum : avoir des avis extérieurs de personnes compétentes est très intéressant !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.