L'un des gros avantages (qui est commun aux features branches et qui contredit _ il n'y a pas de différence notable entre un mec qui développe dans son workspace sans soumettre son code et sans mettre à jour sa base de code et le feature branche_) est que le code de la nouvelle feature, bien que partiellement désactivé en prod, était dans la CI, les tests se jouaient dessus en permanence,
C'est là, je pense, qu'il y a beaucoup de confusions lors des échanges sur le sujet.
Pour certains une "feature branch", c'est une branche locale dans laquelle on commite plusieurs fois. On la ré agence avant de pusher, on la maintient à jour avec le master avec des pull en rebase ou en merge.
Et l'anaphore de barmic prend tout son sens: C'est un espace privé au même titre qu'un workspace SVN et pour pousser l'analogie encore plus loin, les nostalgiques de SVN peuvent se contenter de commit --amend jusqu'au moment du push. Dans mes propos, lorsque je mets en garde contre les feature branch, ce n'est pas de ça dont je parle. Au contraire, travailler dans le trunk ne dispense pas des bonnes manières à coup de rebase interactive.
Pour d'autres (c'est à ça que je fais référence) c'est un espace partagé. C'est là que plusieurs devs pushent sur un serveur, que tournent les tests d'intégrations et que des workflows d'approbation à base de code review pre-merge se mettent en place. Ce n'est pas parce que le serveur d'intégration tourne qu'on fait de la CI (j'y reviendrai). Dans ce type d'espace, on ne peut pas se permettre des rebase en permanence par rapport à master à coup de --force car réécrire l'historique en déplaçant la ref de branche distante a des conséquences sur tous les devs, si la feature n'est pas complète. C'est pour ça qu'on passe par du merge ou par un squash (https://github.com/blog/2141-squash-your-commits).
Un modèle intermédiaire vient avec les outils à la Github et les workflows à la « fork+pull request ». Ici on dispose d’un espace public mais exclusif. On publie sa branche sur le serveur, on peut y faire tourner la CI (détection de branche automatique), mais il reste privatif car dédié à un seul dev en écriture. Le dev recalé lors de la review peut donc republier ses modifs en soumettant sa pull request après un rebase. L’intégration est prise en charge par le serveur en automatique (squash+rebase ou merge, validation par un intégrateur, par quota de reviewer ...). Ca convient pour du dev open source avec des contributeurs de tous horizons, y compris occasionnels, mais pour du dev en entreprise autour d’une équipe resserrée ça commence à devenir un peu lourd comme process, pour intégrer au fil de l’eau. En tout cas, si on passe par un intégrateur comme goulot d’étranglement, qu’on ne vienne pas me dire que c’est de la CI. On peut discuter des mérites, mais ce n’est pas de la CI (cf. plus bas). D’autres éditeurs (Atlassian) ont contourné le problème en évitant de passer par la case "fork" et en jouant sur les permissions au niveau des branches du repo central. Ca améliore le truc mais ça reste lourd. Le workflow que tu nous avais présenté dans un journal est dans la même veine même si plus léger (l'exlusivité est une pure convention) et indépendant d’une review ou d’un intégrateur.
Mais la conséquence de tout ça, c’est que la feature est sous la conduite d’un seul gus. Niveau granularité, ça se limite donc plutôt à une task qu’une User Story (sinon repart dans le travers des long lived) et ça rend assez caduque l’argument sur l’intégration d’une US quand elle est prête.
Concernant la CI. C’est pareil, il faut bien s’entendre sur le vocabulaire. Ce n’est pas parce que tu balances une branche sur ton serveur de CI que tu fais de la CI. Le principe de base de la CI, c’est que tout le monde intègre dans la mainline . Je vous renvoie sur un autre lien de Martin Fowler, pour savoir de quoi on cause.
Mais bon, on s’écarte du sujet initial avec l’agilité et les feature branch. Ce qui m’a fait bondir à la base, c’est qu’on en voit toujours nous ressortir le GitFlow comme la solution à tous nos problème y compris en agilité. J’ai exposé quelques arguments pour démontrer à quel point c’est faux et que chaque projet a son contexte et que le workflow universel n’existe pas. Et je suis assez satisfait de découvrir que d’autres ont émis des réserves semblables aux miennes. Je vous invite à les lire car ça rentre bien dans les détails.
[^] # Re: Workflow git
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3.
C'est là, je pense, qu'il y a beaucoup de confusions lors des échanges sur le sujet.
Pour certains une "feature branch", c'est une branche locale dans laquelle on commite plusieurs fois. On la ré agence avant de pusher, on la maintient à jour avec le master avec des pull en rebase ou en merge.
Et l'anaphore de barmic prend tout son sens: C'est un espace privé au même titre qu'un workspace SVN et pour pousser l'analogie encore plus loin, les nostalgiques de SVN peuvent se contenter de commit --amend jusqu'au moment du push. Dans mes propos, lorsque je mets en garde contre les feature branch, ce n'est pas de ça dont je parle. Au contraire, travailler dans le trunk ne dispense pas des bonnes manières à coup de rebase interactive.
Pour d'autres (c'est à ça que je fais référence) c'est un espace partagé. C'est là que plusieurs devs pushent sur un serveur, que tournent les tests d'intégrations et que des workflows d'approbation à base de code review pre-merge se mettent en place. Ce n'est pas parce que le serveur d'intégration tourne qu'on fait de la CI (j'y reviendrai). Dans ce type d'espace, on ne peut pas se permettre des rebase en permanence par rapport à master à coup de --force car réécrire l'historique en déplaçant la ref de branche distante a des conséquences sur tous les devs, si la feature n'est pas complète. C'est pour ça qu'on passe par du merge ou par un squash (https://github.com/blog/2141-squash-your-commits).
Un modèle intermédiaire vient avec les outils à la Github et les workflows à la « fork+pull request ». Ici on dispose d’un espace public mais exclusif. On publie sa branche sur le serveur, on peut y faire tourner la CI (détection de branche automatique), mais il reste privatif car dédié à un seul dev en écriture. Le dev recalé lors de la review peut donc republier ses modifs en soumettant sa pull request après un rebase. L’intégration est prise en charge par le serveur en automatique (squash+rebase ou merge, validation par un intégrateur, par quota de reviewer ...). Ca convient pour du dev open source avec des contributeurs de tous horizons, y compris occasionnels, mais pour du dev en entreprise autour d’une équipe resserrée ça commence à devenir un peu lourd comme process, pour intégrer au fil de l’eau. En tout cas, si on passe par un intégrateur comme goulot d’étranglement, qu’on ne vienne pas me dire que c’est de la CI. On peut discuter des mérites, mais ce n’est pas de la CI (cf. plus bas). D’autres éditeurs (Atlassian) ont contourné le problème en évitant de passer par la case "fork" et en jouant sur les permissions au niveau des branches du repo central. Ca améliore le truc mais ça reste lourd. Le workflow que tu nous avais présenté dans un journal est dans la même veine même si plus léger (l'exlusivité est une pure convention) et indépendant d’une review ou d’un intégrateur.
Mais la conséquence de tout ça, c’est que la feature est sous la conduite d’un seul gus. Niveau granularité, ça se limite donc plutôt à une task qu’une User Story (sinon repart dans le travers des long lived) et ça rend assez caduque l’argument sur l’intégration d’une US quand elle est prête.
Concernant la CI. C’est pareil, il faut bien s’entendre sur le vocabulaire. Ce n’est pas parce que tu balances une branche sur ton serveur de CI que tu fais de la CI. Le principe de base de la CI, c’est que tout le monde intègre dans la mainline . Je vous renvoie sur un autre lien de Martin Fowler, pour savoir de quoi on cause.
Mais bon, on s’écarte du sujet initial avec l’agilité et les feature branch. Ce qui m’a fait bondir à la base, c’est qu’on en voit toujours nous ressortir le GitFlow comme la solution à tous nos problème y compris en agilité. J’ai exposé quelques arguments pour démontrer à quel point c’est faux et que chaque projet a son contexte et que le workflow universel n’existe pas. Et je suis assez satisfait de découvrir que d’autres ont émis des réserves semblables aux miennes. Je vous invite à les lire car ça rentre bien dans les détails.