Discussion :

[EyZox]

Bonjour,

J'utilise git pour versionner mon projet.
Je fais tourner mon programme dans 4 environnements différents.
Pour faire simple, mon programme utilise une API sans laquelle il ne peut pas fonctionner.
Les 4 environnements de développement correspondent a chaque version majeur de l'API.

J'ai fais 5 branches :
- API v1
- API v2
- API v3
- API v4
- API v4-Dev

Lorsque j'améliore mon programme ou que je lui ajoute des fonctionnalités, je travail sur la branche -Dev.
J'aimerai pouvoir reporter les modifications/ajouts effectué sur ma branche -Dev sur toutes les autres branches.
Avec la branche API v4 le merge ne pose pas de problème puisque j'utilise la même version de l'API, mais ce n'est pas le cas pour la v1,v2,v3.
J'aimerai reporter uniquement les modifications de la branche -Dev et ensuite faire les modifications branche par branche pour rendre les modifications de la branche -Dev compatible avec les différentes version d'API.
J'aimerai ensuite supprimer la branche -Dev et en faire une nouvelle.

On trouve beaucoup d'info sur internet, beaucoup trop et je m'y perd un peu.
J'ai compris que le merge n'étais pas la solution, mais je ne sais pas si je dois utiliser rebase (je ne sais pas non plus comment l'utiliser pour mon cas), cherry-pick ou patch.
Pouvez-vous m'aider ?

Je suis surement hors-sujet avec ce type de question et j'en suis désolé, je ne sais jamais où poster les questions de ce genre :/

[Marco46]

Tu ne donnes pas assez d'info.

Il y a un problème d'architecture à tirer au clair avant de poser la question du workflow git à utiliser.

Pourquoi as-tu besoin de maintenir 4 versions de ton API ? Pourquoi cela correspond à des environnements chez toi ?

Des environnements normalement c'est par exemple (on peut en intercaler d'autres selon les process d'entreprise) :
- développement
- intégration (pour voir comment le programme s'intègre avec un autre programme)
- pre-prod (pour voir comment le programme se comporte dans un environnement ISO prod)
- prod (ce qui est à dispo des utilisateurs / clients)

Après tu as des versions de ton programme. Si par exemple ton programme est un serveur exposant des API REST, il est courant de devoir maintenir plusieurs versions de cette API parce que des applications utilisent ces API. Mais il ne s'agit pas d'environnement, mais de versions.

Ainsi, si tu as 4 versions de ton API, chaque version de cette API dispose de tous les environnements (dev, integration, pre-prod, prod).

Ca signifie que dans ton git, tu devrais avoir 4 lignes de développement formalisées par 4 branches :
- dev-api-v1
- dev-api-v2
- dev-api-v3
- dev-api-v4

Pour transférer un changement d'une branche vers une autre, tu ne peux pas faire de merge sinon tes branches vont se rejoindre et il n'y aura plus deux versions différentes. Merge signifie fusion, donc si tu fais un merge, tu fusionnes de branches et donc 2 versions.

Tu ne peux au mieux que faire des cherry-pick de certains commits suffisamment atomiques d'une branche vers une autre. Mais tu vas rapidement arriver sur des problèmes de dépendances qui vont te forcer à effectuer du dev spécifique sur chaque branche. Pas le choix !

Pour ce qui est du rebase ça n'a absolument rien à voir. Ce petit memo pourra peut être t'éclairer sur la différence entre merge et rebase.

J'ai pas encore creusé les patchs.

[EyZox]

Merci pour ton aide,
J'essaie d'être le plus général possible afin d'isoler au mieux le problème.
Plus précisément il s'agit d'un mod pour le jeu minecraft.
Grosso-modo le jeu change de version tout les 6 mois, et je dois maintenir mon code sur plusieurs version du jeu.

En effet, après lecture de ta réponse, je comprend que ce n'est pas des environnements mais des versions.

J'ai donc une branche pour chaque version du jeu.
Ce scénario illustrera surement mieux les choses :

- La dernière version du jeu est la 1.8
- Je commence le développement sur mon unique branche "1.8"
- La version 1.9 du jeu sort
- Je crée un nouvelle branche "1.9" et j'effectue toutes les modifications pour que mon code soit compatible avec la version 1.9 du jeu
- Je continue le développement de mon mod sur la branche 1.9
- Je souhaite sortir une release, pour la 1.9 pas de problème mais pour la 1.8 :
- Il faut que je reporte les modifications de la ligne en pourpre mais pas celle de la ligne en rouge
- Il faut que je modifie la code de la ligne pourpre pour qu'il soit compatible avec la version 1.8 du jeu.

En attendant (Je n'avais pas encore lu ta réponse), j'ai fais :
- sur la branche 1.9 : git checkout -b "1.8-patch"
- sur la branche "1.8-patch" : git rebase -i -Xtheirs 1.8
- J'ai drop les commits de la ligne rouge
- J'ai fais des commits pour la ligne en bleu
- git checkout 1.8
- git merge 1.8-patch
- git branch -d 1.8-patch
- git push

Ça fonctionne, même si j'imagine que je perds la logique de mon historique au niveau des différentes branches.
J'essayerai avec le cherry-pick pour mes prochaines release.
Est-ce que ce serait plus adapté ? Ou faut-il utiliser carrément autre chose ?

[Marco46]

Ton problème est plus large à mon avis, qu'est ce qui te dit que les développements que tu fais sur la version 1.9 (la ligne pourpre) sont compatibles avec la 1.8 ? Si tu utilises de nouvelles features introduites en 1.9 ou/et si des features de la 1.8 ont subi des breaking changes en 1.9 ton code de la ligne pourpre ne sera pas fonctionnel en 1.8.

Que ce soit un merge, un rebase ou un cherry-pick tu as un problème.

D'où la difficulté de faire ce que tu souhaites faire.