Derniers messages sur Zeste de Savoirhttps://zestedesavoir.com/forums/2021-05-28T23:55:29+02:00Les derniers messages parus sur le forum de Zeste de Savoir.Git: des branches pour multi version, message #2347262021-05-28T23:55:29+02:00Jugid/@Jugidhttps://zestedesavoir.com/forums/sujet/15382/git-des-branches-pour-multi-version/?page=1#p234726<p>Bonjour,</p>
<p>Personnellement, si les versions changent <strong>vraiment</strong> 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.</p>
<p>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").</p>
<p>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.</p>
<p>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é)</p>
<p>Bonne soirée ! J’essayais d’apporter quelques solutions supplémentaires.</p>Git: des branches pour multi version, message #2346682021-05-27T14:50:13+02:00Nek/@Nekhttps://zestedesavoir.com/forums/sujet/15382/git-des-branches-pour-multi-version/?page=1#p234668<p>Oui c’est beaucoup plus clair.</p>
<p>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.</p>
<p>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.</p>
<p>M’est avis que c’est vraiment compliqué, et surtout ton historique GIT ne va ressembler à rien !</p>Git: des branches pour multi version, message #2346662021-05-27T13:44:01+02:00strabelsi/@strabelsihttps://zestedesavoir.com/forums/sujet/15382/git-des-branches-pour-multi-version/?page=1#p234666<p>Merci amael pour votre explication. </p>
<p>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. </p>
<p>Est ce que c’est un peu clair ?</p>
<p>Note: traduire cad comment je peux créer une arborescence git en se basant sur arborecence fonctionnelle</p>Git: des branches pour multi version, message #2346642021-05-27T13:14:45+02:00amael/@amaelhttps://zestedesavoir.com/forums/sujet/15382/git-des-branches-pour-multi-version/?page=1#p234664<p>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.</p>
<p>Dans ton cas, tu aurais donc deux dépôts, <code>projet1</code> et <code>projet2</code>, avec chacun une branche <code>master</code> ou <code>stable</code> qui pointe sur une version stable, et des branches de feature, dev, etc… au besoin.</p>
<p>Un schéma souvent utilisé pour les branches est le git flow dont voici une illustration.</p>
<p><img src="https://git-flow.readthedocs.io/fr/latest/_images/gitflow.png"></p>
<p>Sur cette illustration, chaque point est un commit, et chaque ligne verticale une branche.</p>
<p>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.</p>
<hr>
<p>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, <code>projet1</code> et <code>projet2</code> ou est-ce que ce sont des projets différents?</p>
<p>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.</p>Git: des branches pour multi version, message #2346612021-05-27T12:54:10+02:00sgble/@sgblehttps://zestedesavoir.com/forums/sujet/15382/git-des-branches-pour-multi-version/?page=1#p234661<p>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.</p>
<p>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.</p>
<p>Tu as plusieurs projets, je vois. Il peut être intéressant de faire un <em>repo</em> Git par projet, tout comme il peut être pertinent de faire un seul <em>repo</em> 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.</p>
<p>Cependant, ce n’est pas une règle absolue et chaque cas mérite son étude spécifique.</p>Git: des branches pour multi version, message #2346602021-05-27T12:53:33+02:00strabelsi/@strabelsihttps://zestedesavoir.com/forums/sujet/15382/git-des-branches-pour-multi-version/?page=1#p234660<p>Merci pour ta réponse. </p>
<p>Ce que j’ai présenté dans le lien est l’architecture fonctionnelle du projet. </p>
<p>Mon besoin est de traduire cette architecture en branches git. master —> Develop —>…..</p>Git: des branches pour multi version, message #2346582021-05-27T12:45:17+02:00Nek/@Nekhttps://zestedesavoir.com/forums/sujet/15382/git-des-branches-pour-multi-version/?page=1#p234658<p>Hello,</p>
<p>Je crois que je ne comprends pas bien ce que tu veux dire par architecture GIT. <a href="https://zestedesavoir.com/contenus/beta/1293/comprendre-git/">Il existe un tuto en béta à ce sujet</a>, je te recommande sa lecture… Pour l’instant ce que tu dis ne veut pas dire grand chose.</p>
<p>Peux tu nous en dire plus ?</p>Git: des branches pour multi version, message #2346562021-05-27T12:37:19+02:00strabelsi/@strabelsihttps://zestedesavoir.com/forums/sujet/15382/git-des-branches-pour-multi-version/?page=1#p234656<p>Bonjour, </p>
<p>Nous avons un nouveau projet qui va démarrer.
l’architecture fonctionnel est présentée dans ce lien.</p>
<p><a href="https://ibb.co/ZxB3PVx">Architecture fonctionnelle </a></p>
<p>Mon problème est que je n’arrive pas à traduire cette architecture en arborescence git. </p>
<p>Pourriez-vous m’aider svp ?</p>De l'utilistation de git-flow dans la vraie vie, message #2078052019-08-25T20:59:16+02:00Heziode/@Heziodehttps://zestedesavoir.com/forums/sujet/12913/de-lutilistation-de-git-flow-dans-la-vraie-vie/?page=1#p207805<p>Perso, je l’utilise sur <a href="https://github.com/FOE-Tools/FOE-Tools.github.io">un de mes projets open-source</a>, mais en « modifier ». Ok, j’ai une branche develop, une master (qui est nommé production, car la master contient le site compilé (GitHub Pages)) et je bosse avec un système de fork avec les sous branches (features, bugfix, etc.) sur le fork et pour lesquels je fais des PRs pour éviter justement le bazarre sur les branches develop et production.</p>
<p>J’ai également fait adopter ce système pour certains projets dans la boîte où je bosse, mais c’est pour des secteurs d’activité et des façons de travail qui ont un long processus. Typiquement, entre le temps où la fonctionnalité est sur le master, que c’est livré au client, et qu’ils l’utilisent en production par le client, ça peut prendre quelques mois, années.</p>
<p>Après, je pense que c’est majoritairement utilisé en web et Cie, car (de mon point de vue) ça facilite le processus de dev, en tout cas ça le rende plus clair.</p>
<p>PS: le plugin de JetBrains est une tuerie.</p>
<p>Avec git-flow + <a href="https://semver.org/">Semantic Versioning</a> + <a href="https://www.conventionalcommits.org/en/v1.0.0-beta.4/">Conventional Commits</a>, on a (toujours de mon point de vue) le combot gagnant.</p>De l'utilistation de git-flow dans la vraie vie, message #2077892019-08-25T13:08:34+02:00Ekron/@Ekronhttps://zestedesavoir.com/forums/sujet/12913/de-lutilistation-de-git-flow-dans-la-vraie-vie/?page=1#p207789<p>Je l’ai déjà utilisé sur plusieurs projets et honnêtement, c’est plutôt simple à comprendre.</p>
<p>Je trouve que le modèle de branche proposé est plutôt cohérent et à partir de là, les commandes sont assez logiques et encapsulent complètement le fonctionnement interne de git.</p>
<p>Même pour quelqu’un qui n’est pas très familier de la gestion de version, je pense que c’est accessible. Le système maintient deux branches permanentes en parallèle (develop et master) qu’il met à jour automatiquement et de manière parfaitement transparente en fonction des branches temporaires (features, releases, hotfixes…) ce qui fait que l’utilisateur n’a pas à s’inquiéter qu’il y ait un retard sur l’une ou l’autre branche.</p>
<p>Après, le risque c’est que ce n’est pas restrictif dans le sens ou personne ne pourra empêcher quelqu’un qui ne fait pas attention de développer sur la branche master par exemple. Je pense qu’il y a quand même besoin de comprendre un peu comment fonctionnent les différentes branches mais on peut laisser le système gérer toutes les fusions et c’est quand même un plus appréciable je trouve.</p>
<p>La différence principale avec un système de Pull Requests c’est que tout se passe sur un seul repository, donc difficile d’empêcher quelqu’un de tout casser (volontairement ou involontairement).</p>
<p>À noter que sur les IDEs de chez JetBrains, il y a même <a href="https://plugins.jetbrains.com/plugin/7315-git-flow-integration">un plugin</a> simple d’utilisation qui intègre les commandes directement dans l’interface du logiciel.</p>De l'utilistation de git-flow dans la vraie vie, message #2077862019-08-25T09:30:39+02:00gustavi/@gustavihttps://zestedesavoir.com/forums/sujet/12913/de-lutilistation-de-git-flow-dans-la-vraie-vie/?page=1#p207786<p>Bonjour,</p>
<p>Je viens récemment de découvrir git-flow, un utilitaire pour facilement utiliser git. J’aurai aimé savoir si certains l’ont utilisé dans la vraie vie et ce que vous en pensez de manière générale : <strong>facilité d’utilisation, prise en main, avis par rapport à d’autres outils</strong>.</p>
<p>Actuellement je travaille avec "fork + PR/MR" et "push to master yolo" selon les différents projets auxquels je participe. Le contexte de l’utilisation de gitflow serait pour un petit projet faisant intervenir un petit nombre de personnes (moins de 10) connaissant git mais n’ayant pas nécessairement des connaissances super avancées sur le sujet.</p>
<ul>
<li><a href="https://www.gitflow.com/">Site officiel</a></li>
<li><a href="https://danielkummer.github.io/git-flow-cheatsheet/index.fr_FR.html">Cheat-sheet pour tout comprendre sur le fonctionnement de git-flow</a></li>
<li><a href="https://github.com/nvie/gitflow">Dépôt git</a></li>
</ul>Dépôt GIT en submodule, message #2064052019-07-27T00:02:19+02:00anonyme/@anonymehttps://zestedesavoir.com/forums/sujet/12770/depot-git-en-submodule/?page=1#p206405<p>Finalement, j’ai décidé de cloner le module dans un répertoire voisin au projet et de l’installer (<code>npm i ../module</code>). Ce n’est pas l’idéal mais ça fonctionne beaucoup mieux ! <img src="/static/smileys/smile.png" alt=":)" class="smiley"> c’est dommage, le concept de submodule me plaisait bien …</p>Dépôt GIT en submodule, message #2063432019-07-25T20:21:20+02:00anonyme/@anonymehttps://zestedesavoir.com/forums/sujet/12770/depot-git-en-submodule/?page=1#p206343<figure><blockquote>
<p>Toutes mes expériences avec les sous-modules (dont des pro sur du gros projet) se sont soldées par le même constat : le concept est intéressant, en pratique c’est la plaie. Je pense que c’est efficace seulement si les sous-modules n’évoluent que rarement.</p>
</blockquote><figcaption><a href="https://zestedesavoir.com/forums/sujet/12770/depot-git-en-submodule/?page=1#p206340">SpaceFox</a></figcaption></figure>
<p>Merci pour ta réponse. Alors qu’est-ce que tu me conseillerai ?</p>
<p>Le but étant que je ne perde pas trop de temps à modifier le module en question. Pour un projet perso, j’avais joué avec les symlinks : deux dépôts GIT (le projet & le module), puis j’avais créé un lien symbolique <code>~/git/projet/node_modules/module</code> vers <code>~/git/module</code>. Je trouve ça (ultra) sale, dès que tu fais un <code>npm install</code> dans le projet t’es marron … d’où les sous-modules. J’ai sûrement louper quelque chose quand même - ça me paraît bizarre que je n’ai pas pu retrouver le sous-module, c’est comme si la configuration était restée sur mon PC.</p>Dépôt GIT en submodule, message #2063402019-07-25T19:52:09+02:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/12770/depot-git-en-submodule/?page=1#p206340<blockquote>
<p>Puis m’est venu à l’esprit d’utiliser des sous-modules Git. Est-ce une bonne idée ? </p>
</blockquote>
<p>Toutes mes expériences avec les sous-modules (dont des pro sur du gros projet) se sont soldées par le même constat : le concept est intéressant, en pratique c’est la plaie. Je pense que c’est efficace seulement si les sous-modules n’évoluent que rarement.</p>Dépôt GIT en submodule, message #2063392019-07-25T19:40:01+02:00anonyme/@anonymehttps://zestedesavoir.com/forums/sujet/12770/depot-git-en-submodule/?page=1#p206339<p>Bonjour Zesteuse / Zesteur citronné,</p>
<p>Je suis en plein développement d’une application React pour mon entreprise et j’ai besoin de modifier un module externe spécifique pour l’adapter aux besoins du cahier des charges.</p>
<p>Dans un premier temps, j’ai décidé de fork le module. Puis je me suis retrouvé devant la première contrainte : comment je peux tester mon code ? L’idéal ce serai de pouvoir le tester dans l’application que je développe pour choisir quelles modifications apporter. En dehors du contexte, ça devient franchement compliqué d’avancer (je tiens à préciser que le node module est un gros composant React, ce n’est pas un simple bouton).</p>
<p>Puis m’est venu à l’esprit d’utiliser des sous-modules Git. Est-ce une bonne idée ? Encore maintenant, je n’en sais rien. J’ai pu placer mon fork GIT dans un répertoire, en l’occurrence dans <code>/src/vendors</code>. Cette méthode offre la possibilité de modifier le code source, de compiler le script et d’être importé depuis le composant utilisant le node_modules (puis-ce qu’un lien symbolique est créé dans les node_modules de mon application). Chouette !</p>
<p>Après quoi, je crée un commit avec toutes ces modifications dans la branche <em>dev</em>. Pour vérifier que tout est bon, je checkout sur la branche <em>master</em> - là mystérieusement le répertoire du sous-module dans <code>/src/vendors</code> ne disparaît pas … je décide de supprimer le répertoire à la main avant de revenir à la branche dev. Puis à partir de ce moment là, je n’ai plus jamais réussi à re-télécharger mon sous-module (le répertoire est définitivement vide, même en tapant <code>git submodule update --init --recursive</code>). Il était pourtant bien inscrit dans le fichier <code>.git/config</code>.</p>
<p>Ne comprenant pas, je tente de cloner le projet à côté ; checkout sur la branche <em>dev</em> puis initialisation des sous-modules ; est-ce bien <code>git submodule update --init --recursive</code> ? En tout cas, rien ne s’est passé comme prévu ; le sous-module semble perdu à tout jamais ! Le sous-module n’apparaît même pas dans le fichier de config. J’ai décidé d’enlever le commit que j’avais fait sur la branche <em>dev</em> (force push) pour revenir juste avant mon schmilblick.</p>
<p>Qu’en pensez-vous ? Ce que je veux c’est simplement pouvoir modifier le module dans le même environnement que mon projet ; sachant que je n’ai absolument aucune envie de mélanger mes dépendances avec celles du module (et puis en plus, il a ses propres méthodes de compilation, ça ne serait pas raisonnable de les coupler).</p>
<p>Merci beaucoup pour votre aide.</p>Problème logiciel Git, message #1408102017-02-11T20:48:38+01:00Jérémy Duval/@J%C3%A9r%C3%A9my%20Duvalhttps://zestedesavoir.com/forums/sujet/7800/probleme-logiciel-git/?page=1#p140810<p>Salut,</p>
<p>Du coup j’ai changé d’interface et je suis passé sous GitKraken.
Merci de ton aide <img alt=":)" src="/static/smileys/smile.png"></p>Problème logiciel Git, message #1388872017-01-17T17:29:03+01:00Kje/@Kjehttps://zestedesavoir.com/forums/sujet/7800/probleme-logiciel-git/?page=1#p138887<p>Salut,</p>
<p>Avec <a href="http://lmgtfy.com/?q=SourceTree+git+virtualalloc">une petite recherche google</a> j’ai trouvé <a href="http://stackoverflow.com/questions/18502999/git-extensions-win32-error-487-couldnt-reserve-space-for-cygwins-heap-win32">ça</a> qui semble expliquer ton problème et propose plusieurs façon de le résoudre.</p>
<p>edit : <strong>TL;DR</strong> : A priori il suffit de rebooter ton pc</p>
<p>Bonne chance, ça semble être un problème pur-windows je pourrais pas t’aider plus.</p>Problème logiciel Git, message #1388822017-01-17T16:44:10+01:00Jérémy Duval/@J%C3%A9r%C3%A9my%20Duvalhttps://zestedesavoir.com/forums/sujet/7800/probleme-logiciel-git/?page=1#p138882<p>Bonjour,</p>
<p>Je ne peux plus utiliser SourceTree, mon logiciel pour Git. A chaque action, pour chque projet, j’obtient l’erreur suivante :</p>
<figure><img alt="" src="/media/galleries/3800/b0b51ec1-efa4-46e1-b1a2-7a057b5deba4.png"><figcaption>Erreur SourceTree</figcaption>
</figure>
<p>Voilà voilà, j’espère que vous pourrez m’aider.</p>
<p>Merci d’avance <img alt=":)" src="/static/smileys/smile.png"></p>Commencer un projet, message #158682014-08-11T09:33:53+02:00Vayel/@Vayelhttps://zestedesavoir.com/forums/sujet/1015/commencer-un-projet/?page=1#p15868<p>Merci à vous !</p>Commencer un projet, message #158642014-08-11T09:28:29+02:00Axylium/@Axyliumhttps://zestedesavoir.com/forums/sujet/1015/commencer-un-projet/?page=1#p15864<p>Je crois que tu as mal compris ma phrase. <img alt="^^" src="/static/smileys/hihi.png"></p>
<p>Je suis entièrement d'accord avec toi, sur le fait que utiliser Git dès le début d'un projet peut-être utile et pratique !</p>
<p>C'est pour cela que j'ai employé le terme de bizarre pour qualifier le fait qu'il doit attendre qu'il ai finit le dév' de son logiciel. Car il ne profiterait alors pas des fonctionnalité que lui offre ce dernier !</p>Commencer un projet, message #158632014-08-11T09:22:49+02:00Kje/@Kjehttps://zestedesavoir.com/forums/sujet/1015/commencer-un-projet/?page=1#p15863<blockquote>
<p>c'est que je trouve cela bizarre que tu devrais attendre que ton logiciel soit fini pour le mettre sur GH.</p>
</blockquote>
<p>Pas forcément. Moi en général je versionne dès les premieres lignes de codes. Ça me permet de profiter de git dès le début, a savoir entre autre pouvoir revenir en arriere ou faire des branches pour des tests. De plus j'utilise des services web comme GH aussi car cela me sert de sauvegarde et de centre de synchro, me permettant de facilement passer le dev d'un PC à l'autre (car j'en utilise plusieurs).</p>
<p>Donc utiliser Git (ou mercurial, ou bazaar, etc.) et Github (ou bitbucket, ou gitlab,…) dès le début d'un projet n'est pas compliqué et peut etre très pratique.</p>
<p>Par contre le gitflow que tu propose n'est lui par forcément adapté. C'est le genre de chose qui est surtout utile quand l'appli arrive à un état stable et que vous bossez a plusieurs. En attendant, c'est relativement peu utile. Donc déjà tant que tu n'a pas produit de release (livré une version stable et complete), ne t'embete pas avec ça et fait ton dev dans master.</p>