> On fait simplement une branche par personne et on merge régulièrement sur la master sur notre repo distant.
A partir du moment ou vous ne mergez que devs finis et testés a chaque fois, c'est OK a mon avis.
Le tout est de ne pas avoir des merges sur master avec des parties inachevées qui nécessitent de merger des compléments, des corrections etc. quand on peut l’éviter.
Si tu as plus d'un truc a développer dans ta branche develop, crées des sous-branches par feature, et ne merges dans ta branche develop que chaque sous-branche finie. Comme ca tu pourras ne merger dans master que périodiquement, et que des trucs en statut fini (et tu pourras corriger si nécessaire dans ta branche develop, si tu reperes un pb avant ton merge periodique dans master), et tu pourras détruire toute les branches d'essai non abouti de dev pour une feature, sans que ca impacte sur rien.
> Je peux passer par la ligne de commande
[en ligne de commande] > git fetch
pour récupérer tout l'historique du depot, pas seulement ce qui concerne la branche master
A ce stade, ton outil devrait voir ta branche en principe, sinon,
[en ligne de commande] > git checkout branchJF
pour passer a ta branche
il y a des trucs qui se font mieux en ligne de commande, parce qu'on a une action plus fine qu'avec les outils wysiwig, donc avoir eu un peu de formation a git (en particulier sur les notions de merge et rebase) n'est pas du luxe.
Et une citation pour la route: "git happens"
A+,
---------------
There's more than what can be linked! -- Iyashikei Anime Forever! -- AngularJS c'est un framework d'engulé! --