Salut,

Je dois mettre en place un Git dans ma boîte et j'ai libre cours à ma fantaisie pour en gérer l'organisation, seulement j'ai pas trop envie que ce soit le bordel donc je viens demander vos avis ici, histoire de voir si je fais pas n'importe quoi.

En gros, pour chaque projet, j'ai envie de faire un repository qui ressemble à ça :

• 1 branche Master
• 1 branche par bug levé par le client
• 1 branche à chaque fois qu'un développeur se lance dans une nouvelle fonctionnalité
• 1 branche livraison :
  • 1 sous-branche par livraison (la version) contenant le Master et les branches non mergées (s'il y en a)

Le but c'est que la branche Master reste à jour avec un mec qui va se charger de Merge les bugs et les fonctionnalités.

Maintenant je me pose 2 questions/remarques :

• Est-ce une bonne pratique de supprimer les branches une fois que leur contenu est intégré dans le Master ?
• Est-ce grave de ne pas avoir de branche par développeur ? Je sais que beaucoup font ça mais je n'arrive pas à y voir l'utilité.

Merci !

Si c'est la première fois que tu fais un projet à plusieurs, je te conseil de faire deux branches :

-La branche Master
-La branche Develop

La branche Master contient du code fonctionnel et testé à TOUT MOMENT. Cela veut dire que si je viens sur votre git et que je fais un git clone + compilation, le code roule sans plus d'effort.

La branche Develop contient la dernière version qui est fonctionnel mais pas forcément tester. Cela veut dire qu'il peut y avoir des bugs sous jacent parce que aucun unit test n'a été produit mais qu'en générale, dans un cadre particulier ou attendu, le code fonctionne. Un git clone + compilation doit marcher. Attention, à AUCUN MOMENT un membre de ton équipe ne doit push une version qui ne marche pas/compile pas. C'est vraiment important.

Enfin, si tu veux garder un historique du master (pour les livrables), tu peux faire un milestone sur github afin d'indiquer la version d'un livrable spécifique, et encore mieux, tu peux garder les versions binaires des exécutables dans un dossier dans le Master. Ainsi, si tu veux chercher ton livrable 2, il te suffit de revenir dans l'historique de ton Master.

Je te déconseille, pour une première fois de dépasser 2 branches. C'est du pure suicide car beaucoup de problème de merge vont arriver.

Est-ce une bonne pratique de supprimer les branches une fois que leur contenu est intégré dans le Master ?

Du moment que tu ne supprime pas l'historique, c'est acceptable. Attention au local vs remote dans tous les cas.

Est-ce grave de ne pas avoir de branche par développeur ? Je sais que beaucoup font ça mais je n'arrive pas à y voir l'utilité.

En entreprise, il n'y a que une branche develop par équipe. C'est dire... C'est une très mauvaise pratique d'avoir une branche par développeur.

Disclaimer : je ne suis pas un pro de git, j'ai juste deux-trois questions qui me titillent par rapport aux posts ci-dessus

1 sous-branche par livraison (la version) contenant le Master et les branches non mergées (s'il y en a)

Pourquoi pas simplement des tags ?

Est-ce grave de ne pas avoir de branche par développeur ? Je sais que beaucoup font ça mais je n'arrive pas à y voir l'utilité.

Même chose, je comprends le but du "1 branche par issue/par feature" mais "par développeur" je vois pas

La branche Master contient du code fonctionnel et testé à TOUT MOMENT. Cela veut dire que si je viens sur votre git et que je fais un git clone + compilation, le code roule sans plus d'effort.

C'est plus pratique pour quelqu'un qui veut tester le code, mais est-ce que ce n'est pas plus pratique pour l'ensemble des développeurs que la master soit la branche de dév et qu'il y ait une branche stable/livrables à côté ?

Je te déconseille, pour une première fois de dépasser 2 branches. C'est du pure suicide car beaucoup de problème de merge vont arriver.

Tu déconseillerais d'avoir une branche par issue/feature du coup ? Ca risque pas de devenir le bordel sur la develop que tu conseilles ? Et si des dévs veulent travailler sur une feature en parallèle ? Ils se basent sur un fork d'un "chef de feature" ?

C'est plus pratique pour quelqu'un qui veut tester le code, mais est-ce que ce n'est pas plus pratique pour l'ensemble des développeurs que la master soit la branche de dév et qu'il y ait une branche stable/livrables à côté ?

Ca revient au même. Au final tu fais deux branches, une de dev et l'autre de livrable/stable. Habituellement, le master est la branche de livrable. Pourquoi ? Simplement parce que c'est la Main branch. Y'a pas de git sans Master branch. C'est pour ca qu'il est normalement la branche stable.

Tu déconseillerais d'avoir une branche par issue/feature du coup ? Ca risque pas de devenir le bordel sur la develop que tu conseilles ? Et si des dévs veulent travailler sur une feature en parallèle ? Ils se basent sur un fork d'un "chef de feature" ?

Tout dépends du niveau de skill des développeurs. Si tu as une TRES GROSSE features, alors oui, le conseil d'avoir une nouvelle branche qui fork du DEVELOP branch est une possibilité, pas du master. Sinon, des branches en local seulement suffise largement dans la plupart du temps. Ce que je veux dire c'est que un one man job, ce n'est habituellement pas une TRES GROSSE features quoi. Du coup, un branche suffit pour dev.

De plus dépendamment du langage, tu peux faire en sorte que ton code compromettant soit quand même mis sur git mais soit ignorés pour ne rien briser(en C/C++ les #ifdef sont tes amis). Attention, ca doit quand même marcher dans le cadre normale de son exécution si tu les actives.

Merci pour vos réponses.
Je pense que je vais garder le 1 branche / issue parce que ça sera plus pratique pour nous.

@1234_bou: Le principe de milestone a l'air intéressant et je débute sur Git, je ne connaissais pas cette feature mais nous passons par EGit (plugin de Eclipse) qui ne gère apparemment pas les milestones ^.^.

@PCOffender: Pour les tags, idem que pour les milestones, je ne connaissais pas cette feature, je vais regarder si c'est faisable au travers de EGit.

En ce qui concerne la notion de fork, je ne sais pas si c'est une notion uniquement présente sur GitHub ou si ça fait partie de Git mais nous ne passons pas par GitHub, notre remote repository est sur notre intranet.

Je suppose que si j'installe Git normalement (pas le plugin d'Eclipse), j'aurai accès à ces features mais je me demande s'il ne risque pas d'y avoir un conflit entre les 2, je n'ai jamais vraiment utilisé ça en fait, les seules fois où j'utilisais un gestionnaire de version c'était du googlecode et c'était à l'arrache à base de push/overrides pour des projets à l'université :p

Je reviendrai sûrement lundi pour vous tenir au courant de ce que j'ai mis en place ou pour vous poser d'autres questions

Le fork est commun a git, github n'est qu'une jolie interface de Git

On a décidé de partir sur une branche par Issue et une branche Master. On va faire des tags pour les livraisons Merci à vous

je te conseille une branche master pour le code stable / livrable
une branche hotfix pour les bugs sur master (que tu kill après)
une branche develop qui est une branche théoriquement stable pour les dev
une branche release quand la dev est en passe de passer en master pour une livraison
une branche par feature que tu merge dans develop quand c'est stable (et delete après)

Ca permet de rester carré sur les process

https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow