sly a écrit :Juste pour bien comprendre : on push sur la branche master directement nos modifs c'est ça que tu as en tête ?
Oui. Et les espaces perso pointent sur master.
sly a écrit :Et on ne se sert de la branche dev que si vraiment on doit lancer un nouveau chantier qui risque fort de créer des bugs importants ?
Voir la geler quitte à en fourchetter une autre à partir du maître quand un gros chantier se profilera à l'horizon.
Sinon, on va rapidement tester sur un dev obsolète ou recréer la complexité du merge dans l'autre sens.
Voir la geler quitte à en fourchetter une autre à partir du maître quand un gros chantier se profilera à l'horizon.
Sinon, on va rapidement tester sur un dev obsolète ou recréer la complexité du merge dans l'autre sens.
ok pour le principe, après, en terme de commandes à taper, j'ai l'impression que :
git ckeckout dev
git pull origin master
(pour remettre à jour la branche dev par rapport à master)
est plus simple que détruire l'ancienne, re-créer la nouvelle et définir la remote
(4 commandes)
sly a écrit :ok pour le principe, après, en terme de commandes à taper, j'ai l'impression que :
git ckeckout dev
git pull origin master
(pour remettre à jour la branche dev par rapport à master)
est plus simple que détruire l'ancienne, re-créer la nouvelle et définir la remote
(4 commandes)
Oui, bien sur. On garde la structure et on ne la merge qu'au moment de s'en servir.
Pas la peine de garder une branche morte avec le dernier DEV dedans
