Discussion :

[jedema]

Bonjour,

Je commence à utiliser git depuis quelques mois maintenant.
Après avoir lu pas mal de docs je me pose toujours une question concernant les branches.

Prenons le cas d'un projet où on a trois branches :

master : Branche en cours de développement
1.1.1 : Branche stable dérivée de master qui ne reçoit que des correctifs.
calendrier : Branche expérimentale qui doit recevoir les correctifs et les nouvelles fonctionnalités

Je vais prendre ensuite deux cas :

Premier cas : je corrige un bug sur le site puis je commit. Mes deux branches seront alors mises à jour lorsque je ferai un git pull sur mes branches.

Deuxième cas : je développe une nouvelle fonctionnalité et je veux qu'elle apparaisse sur ma branche "master" et sur ma branche "calendrier" sans qu'elle se retrouve sur ma branche 1.1.1.

Pour le premier cas, c'est exactement ce qui se passe lorsque je commit sur "master".
Pour le deuxième cas, je ne sais pas comment faire. Avez-vous une idée de comment je peux faire cela ?

Question supplémentaire : Si a chaque correctif je veux incrémenter la version de mon 1.1.1 en 1.1.2 je dois créer une nouvelle branche ? Ou alors je dois utiliser de systèmes commes les tags ? En tous cas que faut-il faire pour que ce soit "propre" ?

Merci d'avance pour vos réponses

[Logan Mauzaize]

Le principe générale c'est de créer une branche dès lors que le travail diverge.
j'ai eu tendance à abandonner "master" (ou trunk sous SVN) car (et pour d'autres raisons) il est souvent difficile de spécifier ce qu'elle contient exactement.

Dès lors que tu figes quelque chose, tu peux utiliser des tags légers (en fait ce sont simplement des étiquettes sur des commit, comme HEAD, FETCH_HEAD). Lorsque tu génères une nouvelle release, certains conseillent d'utiliser des tags signés. Néanmoins, certains préfère utiliser des branches car elles sont faciles à gérer.

Concernant le travail avec des branches :

• Tu développes généralement sur une branche principale
• Ensuite tu fais une déploies la version (après plusieurs essais) et tu crées un tag ou une branche (ex: 1.0)
• A ce moment là, si ta version peut recevoir des maintenances, tu crées une branche spécifique (ex: 1.0.X)
• Si tu dois faire un patch sur cette version
  
  • Soit tu crées une branche dédiée basée sur la précédente (ex: 1.0.1)
  • Soit tu continues de travailler sur la même branche (ex : 1.0.X) et que tu as finis de travailler tu crées le tag ou la branche correspondant au patch (ex: 1.0.1)
• Si tu dois reporter les modifications, tu merges (ou cherry pick) vers la branche que tu souhaites.
• Je te conseille de nommer les branches expérimentales de manière explicite (ex: PoC_XXX)

Si ce n'est pas fait, je te conseille de lire Pro Git et notemment le chapitre Git distribué (qui aborde l'organisation du travail et l'utilisation de Git)

[jedema]

Merci beaucoup,

je pensais qu'il y avait une sorte de solution miracle mais apparemment non.

Tant pis, j'appliquerai mes patch sur les branches spécifiques.

Bonne soirée et merci

[Logan Mauzaize]

je pensais qu'il y avait une sorte de solution miracle mais apparemment non.

"merge" fait le boulot tant qu'il n'y a pas de conflit.