Définir un workflow de branches
Je ne comprends pas bien l’organisation des branches du projet actuel.
- Il y a des branches de features non mergées mais trèèès en avance
- Il y a des branches releases, mais du coup à quoi sert la branche master ?
- La branche develop est origine de la branche de release 1.0, et master est en arrière…
Bref j’ai pas l’impression qu’il y ait une logique, sinon éclairez-moi je vous prie !
Dans le cas où il faudrait trouver une nouvelle logique, je propose celle qui est décrite sur cette page :
Ça paraît compliqué comme ça, mais ça se fait très bien !
- On développe sur
develop
en passant par des branches desfeature
intermédiaires. - Quand on est satisfait, on fait une branche
release
pour faire tester aux gens - Quand on est satisfait, on merge cette branche de
release
dansmaster
, puis on tag. - En cas de pépin grave, on peut toujours faire des hotfixes n’importe où.
Il faudrait donc protéger les branches suivantes :
-
master
(maintainer only) -
release/*
(maintainer and dev) -
develop
(maintainer and dev)
(pour éviter qu’elles soient écrasées)
Qu’en pensez-vous ?