Bonjour,
Nous avons un nouveau projet qui va démarrer. l’architecture fonctionnel est présentée dans ce lien.
Mon problème est que je n’arrive pas à traduire cette architecture en arborescence git.
Pourriez-vous m’aider svp ?
Hello,
Je crois que je ne comprends pas bien ce que tu veux dire par architecture GIT. Il existe un tuto en béta à ce sujet, je te recommande sa lecture… Pour l’instant ce que tu dis ne veut pas dire grand chose.
Peux tu nous en dire plus ?
Merci pour ta réponse.
Ce que j’ai présenté dans le lien est l’architecture fonctionnelle du projet.
Mon besoin est de traduire cette architecture en branches git. master —> Develop —>…..
Je ne suis pas certain bien comprendre ton besoin, et je ne suis pas sûr de comprendre ce que tu attends d’un outil comme Git.
Git est un gestionnaire de fichiers (de code source, en général) qui sait nativement gérer une arborescence, laquelle correspond simplement à l’arborescence du système (les répertoires et leurs sous-répertoires et les fichiers qu’elle contient). Il n’y a donc rien à « traduire », Git gère ses objets tout seul.
Tu as plusieurs projets, je vois. Il peut être intéressant de faire un repo Git par projet, tout comme il peut être pertinent de faire un seul repo pour plusieurs projets (chacun dans leur répertoire). En général, on favorise la première approche : chaque repo Git est un projet indépendant des autres.
Cependant, ce n’est pas une règle absolue et chaque cas mérite son étude spécifique.
La plupart du temps, avec git, on applique la logique une branche=une version, et un dépôt ou un dossier = un logiciel ou une librairie.
Dans ton cas, tu aurais donc deux dépôts, projet1 et projet2, avec chacun une branche master ou stable qui pointe sur une version stable, et des branches de feature, dev, etc… au besoin.
Un schéma souvent utilisé pour les branches est le git flow dont voici une illustration.
Sur cette illustration, chaque point est un commit, et chaque ligne verticale une branche.
Si les deux projets sont très liés (inséparables l’un de l’autre), il peut être intéressant de n’avoir qu’un seul dépôt, avec deux dossiers, pour versionner les dépendances de l’un par rapport à l’autre facilement.
Je n’ai pas compris la partie "pays" de ton schema, est-ce que tu veux dire qu’il y a deux équipes qui travaillent sur les mêmes projets, projet1 et projet2 ou est-ce que ce sont des projets différents?
Si ce sont les mêmes projets, utilise le même dépôt pour tout le monde, sinon vous risquez d’avoir de gros soucis aux moments des fusions.
Merci amael pour votre explication.
Le besoin est théoriquement ça sauf que: pour un microservice (projet), je peux avoir plusieurs versions (une version qui est dédié pour la france et une autre par exemple pour l’Allemagne). en dessous de chaque version, il y’aura le client qui va avoir ce microservice. et enfin pour ce client, il y’a une branche standard et une autre spécifique.
Est ce que c’est un peu clair ?
Note: traduire cad comment je peux créer une arborescence git en se basant sur arborecence fonctionnelle
Oui c’est beaucoup plus clair.
Et à mon sens ce n’est pas avec GIT que tu vas résoudre ce problème. Il faut que tu ai toutes les versions dans ton projet principal mais tu peux ajouter une configuration pour activer/désactiver certaines parties de ton application.
Avec GIT, le mieux que tu pourrais faire c’est avoir une branche principale qui ne contient aucune spécification et une branche par nouvelle version. Ensuite tu merges la branche principale dans toutes les versions dès que t’en as le besoin.
M’est avis que c’est vraiment compliqué, et surtout ton historique GIT ne va ressembler à rien !
Bonjour,
Personnellement, si les versions changent vraiment d’un pays à l’autre, alors j’aurai fait en sorte d’avoir un repo par pays (version). C’est difficile sinon de gérer les releases de telle ou telle version même si tu peux baser ta release sur la branche X ou Y. Ca ferai brouillon (et ça peut perdre du monde en route). Et plus généralement, ton git flow aussi. Ce n’est que mon avis.
Si c’est qu’une histoire de traduction, tu peux inclure les langues dans ton projet et avoir un système de traduction (à l’instar de celui que pourrai utiliser un "dev Symfony").
Ou si c’est vraiment une question de fonctionnalités (juridique, ou autre) et que tu veux tout inclure dans un seul GIT, il faudra revoir peut-être ton système pour faire comme des "plug-ins" qui s’activent ou se désactivent. Mais je ne fais que répéter ce que disait Nek.
Si jamais tu as une release qui devrait s’appliquer à tout ton soft et ne pas le diviser par pays. L’astuce de Nek est quand même le "Nek plus ultra" (Désolé)
Bonne soirée ! J’essayais d’apporter quelques solutions supplémentaires.
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
