IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

GIT Discussion :

Besoin de bonnes pratiques


Sujet :

GIT

  1. #1
    Membre confirmé
    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2013
    Messages
    191
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : février 2013
    Messages : 191
    Points : 472
    Points
    472
    Par défaut Besoin de bonnes pratiques
    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 :/

  2. #2
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 413
    Points : 19 268
    Points
    19 268
    Par défaut
    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.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  3. #3
    Membre confirmé
    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2013
    Messages
    191
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : février 2013
    Messages : 191
    Points : 472
    Points
    472
    Par défaut
    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 ?

  4. #4
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 413
    Points : 19 268
    Points
    19 268
    Par défaut
    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.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

Discussions similaires

  1. Bonnes pratiques de protections individuelles
    Par Community Management dans le forum Sécurité
    Réponses: 22
    Dernier message: 05/04/2013, 11h47
  2. Réponses: 7
    Dernier message: 02/11/2005, 15h30
  3. [Bonne pratique]Stratégie d'allocation
    Par jowo dans le forum C
    Réponses: 1
    Dernier message: 05/10/2005, 14h47
  4. [FOREIGN K] Valeur de champ = nom de table. Bonne pratique ?
    Par Seb des Monts dans le forum Langage SQL
    Réponses: 9
    Dernier message: 17/05/2005, 10h56

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo