oui on garde toutes les branches, après on se base sur gerrit qui fournit quelques avantages. Toutes ses branches sont des branches de revue gerrit (gerrit crée automatique une nouvelle branche lorsque tu pousse un commit qui a un nouveau gerrit ID dans son commit de message) et c'est des branches spéciales. Spéciales dans le sens quels sont dans un refspec git séparé. Donc oui tu as toutes les branches sur le serveur mais par défaut tu ne les vois jamais. (Pas dans le refspec par défaut).
Comme les branches de revue sont très petites, le log linéaire dans la branche de master suffit la plupart du temps. Si y a une besoin précis, faut aller récupérer la bonne branche (avec le gerrit ID c'est vraiment facile) et la on a accès à tous les commits de la feature mais aussi à tous les commentaires de la revue de code gerrit, les logs de l'intégration continue etc...
La seul limitation de ce workflow c'est si tu as plusieurs "master" (si tu gère plusieurs versions en parallèle genre une branche v1.x et une branche v2.x), si tu veux backporter un commit d'une branches à l'autre on préfère passer par une nouvelle branche de revue et donc changer le gerrit ID et on inclue manuellement l'ancien gerrit ID dans le message de commit. C'est pas obligatoire mais ça permet de si retrouver plus facilement.
Utiliser se workflow sans gerrit demande à mon avis quelques adaptations. Gérer les git refspec à la main ça peut etre assez lourd (quoique à y réfléchir c'est pas si compliqué) et tous avoir dans le même refspec devient vite le bordel.
[^] # Re: Workflow similaire
Posté par Tangi Colin . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 4.
oui on garde toutes les branches, après on se base sur gerrit qui fournit quelques avantages. Toutes ses branches sont des branches de revue gerrit (gerrit crée automatique une nouvelle branche lorsque tu pousse un commit qui a un nouveau gerrit ID dans son commit de message) et c'est des branches spéciales. Spéciales dans le sens quels sont dans un refspec git séparé. Donc oui tu as toutes les branches sur le serveur mais par défaut tu ne les vois jamais. (Pas dans le refspec par défaut).
Comme les branches de revue sont très petites, le log linéaire dans la branche de master suffit la plupart du temps. Si y a une besoin précis, faut aller récupérer la bonne branche (avec le gerrit ID c'est vraiment facile) et la on a accès à tous les commits de la feature mais aussi à tous les commentaires de la revue de code gerrit, les logs de l'intégration continue etc...
La seul limitation de ce workflow c'est si tu as plusieurs "master" (si tu gère plusieurs versions en parallèle genre une branche v1.x et une branche v2.x), si tu veux backporter un commit d'une branches à l'autre on préfère passer par une nouvelle branche de revue et donc changer le gerrit ID et on inclue manuellement l'ancien gerrit ID dans le message de commit. C'est pas obligatoire mais ça permet de si retrouver plus facilement.
Utiliser se workflow sans gerrit demande à mon avis quelques adaptations. Gérer les git refspec à la main ça peut etre assez lourd (quoique à y réfléchir c'est pas si compliqué) et tous avoir dans le même refspec devient vite le bordel.