J'utilise un workflow plutot similaire mais sans rebase en soi.
Mon workflow a moi est le même, on crée des branches tout le temps (pour chaques features, bugs ...)
Par contre au niveau merge on fait du squash + cherrypick de la branche à merger. Ensuite on utilise gerrit qui à la particularité de mettre un ID unique dans le message de commit donc depuis la branches d'intégration ou la master si on veut retrouver le log complet d'une feature, on regarde l'ID dans le commit de message et on retrouve la branche correspondante.
On ne rebase jamais, on ne fusionne jamais les branches, on cherry pick. Si jamais on a intégrer un changement sur la master qui doit etre retiré on le revert tout simplement. (Ce qui normalement n'arrive jamais puisque la branche d'intégration sert à éviter ça).
[^] # Workflow similaire
Posté par Tangi Colin . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 4.
J'utilise un workflow plutot similaire mais sans rebase en soi.
Mon workflow a moi est le même, on crée des branches tout le temps (pour chaques features, bugs ...)
Par contre au niveau merge on fait du squash + cherrypick de la branche à merger. Ensuite on utilise gerrit qui à la particularité de mettre un ID unique dans le message de commit donc depuis la branches d'intégration ou la master si on veut retrouver le log complet d'une feature, on regarde l'ID dans le commit de message et on retrouve la branche correspondante.
On ne rebase jamais, on ne fusionne jamais les branches, on cherry pick. Si jamais on a intégrer un changement sur la master qui doit etre retiré on le revert tout simplement. (Ce qui normalement n'arrive jamais puisque la branche d'intégration sert à éviter ça).
Peut etre que ça peut te convenir comme workflow.