Hello,
perso je fais des branches éphémères, je pense que c'est une méthode assez classique :
nouveauté_du_lundi -> squash+merge dans main
nouveauté_du_mardi -> squash+merge dans main
nouveauté_du_mercredi -> ça prend du temps, le merge sera pour plus tard
nouveauté_du_jeudi -> squash+merge dans main
rebase de la branche main dans nouveauté_du_mercredi (on récupère ce qui était dans nouveauté_du_jeudi au passage)
nouveauté_du_mercredi -> squash+merge dans main
On a comme habitude dans mon équipe de squash les commits intermédiaires, pour n'avoir qu'un commit par branche à la du travail, sauf si vraiment c'est utile de garder les commits séparés.
On ne garde pas de branches séparées longtemps. Les merge dans la branche principale se font par fast-forward.
On rebase souvent la branche principale dans les branches de dev, pour avoir le diff le plus petit par-rapport à la prod. Ceci nous oblige aussi à toujours tester notre code de dev depuis la version la plus à jour possible de la branche principale.
Ça marche bien car on fait plutôt des petits changements, on est une petite équipe, et que les merge avec commit de merge rendent l'historique confus, on préfère rebase et fast-forward.
# Branches à courte durée de vie
Posté par cg . En réponse au message Git - Rebase - Conflits - Worflow ?. Évalué à 7.
Hello,
perso je fais des branches éphémères, je pense que c'est une méthode assez classique :
On a comme habitude dans mon équipe de squash les commits intermédiaires, pour n'avoir qu'un commit par branche à la du travail, sauf si vraiment c'est utile de garder les commits séparés.
On ne garde pas de branches séparées longtemps. Les merge dans la branche principale se font par fast-forward.
On rebase souvent la branche principale dans les branches de dev, pour avoir le diff le plus petit par-rapport à la prod. Ceci nous oblige aussi à toujours tester notre code de dev depuis la version la plus à jour possible de la branche principale.
Ça marche bien car on fait plutôt des petits changements, on est une petite équipe, et que les merge avec commit de merge rendent l'historique confus, on préfère rebase et fast-forward.