Je voudrais troller, je dirais que t'as l'air assez dogmatique dans ton agilité :)
Ce n'est vraiment pas ton genre :)
Un paramètre crucial dans le feature branch, c'est la durée de vie de la branche. Une branch qui vit 2-4 jours (sur un sprint de disons 2 semaines), c'est pas le bout du monde.
Ton intégration continue s'en sortira, et tes merges aussi.
OK, plus ça dure, plus c'est dur (c'est pas comme le sexe).
Quelle est la granularité alors ?
Une branche par épique ? Y'en a que ça n'effraie pas et qui s'en sortir avec une un merge auto from upstream qui casse le build en CI pour forcer la mise à jour
Au niveau de la US, elles ont parfois du mal à tenir en moins de 4 jours surtout. si comme certains le préconisent on colle juste un gus dessus. Multiplie ça par le nb de US de l'équipe et on nage en plein merge hell.
Au niveau de la task ? Bin quel est l'intérêt d'une branche alors ? Vu que tu intègres des bouts de US, tu prends les mêmes risques de livrer une feature non finie et tu retombes dans l'effet tunnel.
Mais tu donnes quelques éléments:
La revue de code en amont. On n'as pas attendu les feature branch pour en faire. Mais c'est vrai que ca se fait en aval. La question mérite d'être discutée. De la revue de code en amont tu la fais au fil de l'eau lorsque tout le monde commites dans trunk. Tu fais du pair programming, ... Suffit de pas puller comme un bourrin et fetcher avant de rebaser. Et le gugusse qui ne respecte pas les coding rules ou qui pète la CI, il va se faire repérer assez vite.
Si je trollais, je dirais que ce worklow te conviens parce que t'aimes bien joué les gros bras ;-)
Le squash pour simplifier le bisect. Si j'étais dogmatique, je dirais que ça ne devrait pas arriver souvent si t'as une batterie de tests qui te préserve de tout ça. Mais franchement 2 itérations de plus sur un bisect (surtout dans un histo linéaire), ce n’est pas le bout du monde. Et si tu bosses pas sur un UI mais sur une API, c'est encore plus simple puisque tu ne te tapes pas tout ça à la mano.
Sinon squash or not squash, c'est un autre débat et il y en a qui sont plus favorables un histo bien découpé
Juste pour être clair - tu comittes/push direct sur master? Genre plusieurs fois par jour?
Indeed, mais comme je suis pragmatique.
rebase -i obligatoire avant un push, et TU+TI mockés en local.
une US ou 2 max à la fois pour toute l'équipe. On est en "scrum" les gars.
Seules les US à risque ont droit à un traitement de faveur. Feature toggling et sinon une feature branch max comme ça pas d'embrouille.
Et pis si vraiment on se ratait, les cadors git qui mergent un refactoring en 2 temps 3 mouvements adeptes du feature branch, ils sont assez frisés pour nous séparer la feature du trunk avec 2 rebase interactive et un push –force, tu ne crois pas ?
Et le mec qui fait un refactoring sans demander si quelqu'un bosse sur la partie refactoree, il mérite un peu des claques, non?
Y’en a encore qui osent refactorer dans ton équipe ?
[^] # 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.
Ce n'est vraiment pas ton genre :)
OK, plus ça dure, plus c'est dur (c'est pas comme le sexe).
Quelle est la granularité alors ?
Une branche par épique ? Y'en a que ça n'effraie pas et qui s'en sortir avec une un merge auto from upstream qui casse le build en CI pour forcer la mise à jour
Au niveau de la US, elles ont parfois du mal à tenir en moins de 4 jours surtout. si comme certains le préconisent on colle juste un gus dessus. Multiplie ça par le nb de US de l'équipe et on nage en plein merge hell.
Au niveau de la task ? Bin quel est l'intérêt d'une branche alors ? Vu que tu intègres des bouts de US, tu prends les mêmes risques de livrer une feature non finie et tu retombes dans l'effet tunnel.
Mais tu donnes quelques éléments:
La revue de code en amont. On n'as pas attendu les feature branch pour en faire. Mais c'est vrai que ca se fait en aval. La question mérite d'être discutée. De la revue de code en amont tu la fais au fil de l'eau lorsque tout le monde commites dans trunk. Tu fais du pair programming, ... Suffit de pas puller comme un bourrin et fetcher avant de rebaser. Et le gugusse qui ne respecte pas les coding rules ou qui pète la CI, il va se faire repérer assez vite.
Si je trollais, je dirais que ce worklow te conviens parce que t'aimes bien joué les gros bras ;-)
Le squash pour simplifier le bisect. Si j'étais dogmatique, je dirais que ça ne devrait pas arriver souvent si t'as une batterie de tests qui te préserve de tout ça. Mais franchement 2 itérations de plus sur un bisect (surtout dans un histo linéaire), ce n’est pas le bout du monde. Et si tu bosses pas sur un UI mais sur une API, c'est encore plus simple puisque tu ne te tapes pas tout ça à la mano.
Sinon squash or not squash, c'est un autre débat et il y en a qui sont plus favorables un histo bien découpé
Indeed, mais comme je suis pragmatique.
rebase -i obligatoire avant un push, et TU+TI mockés en local.
une US ou 2 max à la fois pour toute l'équipe. On est en "scrum" les gars.
Seules les US à risque ont droit à un traitement de faveur. Feature toggling et sinon une feature branch max comme ça pas d'embrouille.
Et pis si vraiment on se ratait, les cadors git qui mergent un refactoring en 2 temps 3 mouvements adeptes du feature branch, ils sont assez frisés pour nous séparer la feature du trunk avec 2 rebase interactive et un push –force, tu ne crois pas ?
Y’en a encore qui osent refactorer dans ton équipe ?