Discussion :

[Spoutch]

Bonjour !

Sur conseils, je me suis enfin mis a git et gitlab pour gérer mes différents projets, mais je ne sais pas encore quelle méthodologie adopter pour l'un d'entre eux.

Je m'explique:

Pour le développement des projets webs, avec le temps, je suis arrivé à une base composée de différents frameworks, des opens sources, mais aussi beaucoup de sources de mon propre crue, bref, un tamplate que je peut réutiliser à chaque foi.

A chaque projet, je reprends cette base, mais je développe aussi des améliorations en plus, propre au projet en cours (aussi souvent des corrections de bugs ^^). A la fin, je réinjecte les corrections et nouvelles fonctions dans le tamplate de base.

La gestion devient compliquer lorsque je me retrouve avec plusieurs projets en parallèle: j'apporte des corrections sur un, que j'injecte aussi parfoi dans l'autre. Aussi pour ce qui est des bugs, je les applique aux anciens, dans la mesure du possible.

L'utilité de git devient évidente, mais j'hésite sur la façon de procéder:

- Un seul repo, dont le tamplate de base serait la branche master, puis une branche pour chaque projet web
- un repo pour chaque projets

Dans le 1er cas, l'inconvénient est qu'il y a a chaque foi un bon morceau des projets que je ne veut pas réinjecter dans la branche principale (le tamplate)

Dans le 2ème cas, la possibilité de comparer des versions différentes de scripts et de les merger me paret ainsi plus compliqué voir compromise.

Qu'en pensez vous?

[Philippe Bastiani]

Ni l'une ni lautre mais les 2

A - Tu peux biensûr avoir un même script sur 2 dépots différents... Dans cette configuration tu as un dépots de référence et des forks (c'est le fonctionnement de Github par exemple). Git te donne tous les outils pour synchroniser tes dépots... mais, IMHO, c'est assez lourd car tu n'as pas d'arbre de dépendance entre tes fork ! L'idée est ici de cloisonner les différents projets pour éventuellement les diffuser auprès de tes clients pourquoi pas... Cette architecture, ne te dispense pas d'avoir plusieurs dépots par projet et/ou template (mix de tes 2 propals) !

B- A contrario, tu peux axer ton architecture sur des dépots différents (par fonctionnalité, ..., ou tout autre découpage)... Ici le problème est de synchroniser le tout. Git te propose 2 solutions :
- simple et empirique : poser un même tag sur tes dépots
- plus complexe à mettre en oeuvre mais Git à 100%: les sous-modules. tu as un dépot de base auquel tu ajoutes des fonctionnalité (mix de tes 2 propals ici aussi). Tu as ainsi un arbre de dépendance cohérent sur l'ensemble de tes sources et ressources.

Comme tu le vois les deux solutions d'archi son possible
- A est orientée projet,
- B est plus orientée fonctionnalité.
Dans les deux cas, tu pourras maintenir la cohérence du tout.

Cdlt,
Philippe

[Spoutch]

Après mettre documenté sur les forks et sous module, je pense que c'est la solution B qui me correspond le mieux.
En effet, mes clients apporte aucune importances a la forme du travaille livré, pourvu que c'est en prod et fonctionnel. De plus j'apport dans les 1er temps une maintenance applicative, et par la suite corrective, il vaut donc mieux que ces projets sois "brancher" sur le projet de base.

Pour être sur d'avoir bien compris les sous module et donc être sur que c'est cela dont j'ai besoin, avant de me documenter d'avantage dessus:

Imaginons que je démarre un projet A, avec pour sous module B et C, faisans partie de ce que j’appelai précédemment mon "template".
J'apporte des modifications sur B et C, je commit, je push.
Si je retourne dans B ou C, un simple pull me permet de récupérer ces modifications?
Si maintenant je retourne sur un vieux projet Z, qui contient les sous module B et C, pull ?
Je suppose qu'un pull ne suffit pas, sinon bonjour les collisions ou autres incompatibilité...donc je doit merger, est-ce aussi simple?

Merci en tout cas pour ton aide ^^

[Philippe Bastiani]

Je t'invite à regarder la tradcution française de PRO Git disponible ici et un petit tuto ici!

Les sous-module git sont des dépots à par entière; et, tu dois synchroniser le dépot source avec les différents sous-modules.... c'est là où il faut de la rigueur !

Personnellement, travaillant en environnement Java, je n'utilise pas cette spécificité de Git (i.e. je travaille avec plusieurs dépots distincts, et le lien des versions/projets est réalisé par la chaîne de build et non pas Git lui-même).

a+
Philippe

[Spoutch]

ok, merci pour les docs! je vais zieuter tout sa.

[Spoutch]

Effectivement, livre très intéréssant et très bien foutu.

Je comprend mieux la rigueur et les risques des sous-modules...
Mais d'un autre coté dans mon cas, je ne vois pas bien comment gérer efficassement les modifications d'un projet a reporter sur d'autre, en utilisant des fork.

Je vais faire des essais sur un projet-test avec les sous module en attendant ^^

[ClemLamb]

Salut Spoutch,

si tu as réussi à paramétrer cet environnement je suis intéressé par la démarche que tu as choisi et comment tu as fait!

Merci d'avance!!
Clem