D’expérience, là où j'ai travaillé, personne n'était assez mature pour faire ça sans complètement exploser la complexité du code et sans se perdre dans toutes les fonctionnalités.
L'agilité ça consiste à discuter au plus tôt sur les questions qui pourraient poser problème. La base de l'agilité c'est l'intégration continue. Tout ce qui y contrevient est malvenu.
Ouai bof, ça n'est pas vraiment un problème. Faut rebaser fréquemment. Sur des petites équipes ça ne pose aucun problème. Ton intégration continue elle doit surtout être toujours verte, tu dois pouvoir livrer à tout moment, à la fréquence qui te semble opportune et pas à la fréquence que tu es capable de faire. Donc non tu ne peux pas accepter qu'un gars commit une erreur ou un truc qui a un effet de bord indésiré. Si tu veux, tu peux contraindre ton IC à faire un rebase fréquent (si la branche à lancer n'est pas assez à jour la passer en erreur).
Ce n'est qu'au moment où vous intégrez que les problèmes arrivent et notamment le big bang merge, les conflits sémantiques et c'est souvent le plus mauvais moment... peu avant la fin du sprint.
Ça n'est pas une vérité générale. J'ai vu une conférence des furets. Ils n'ont pas de master et font systématiquement du big bang merge comme tu dis. Ils ont créé un outils pour ça : git-octopus.
Alors si vous voyez débarquer dans vos équipes un type qui vous vante les mérites du feature branching, et que c'est peanuts avec git et que Git flow c'est une tuerie, le même qui ne s'est jamais paluché un vrai merge des familles avec du refactoring sur le nom des packages et des classes, les changements sur les schémas de base de données, un conseil ... Fuyez !!!
Bof. J'ai tendance à fuir celui qui me dis de fuir. Actuellement j'ai l'impression qu'on a une explosion des workflow et c'est une très bonne chose ! Les gens font ce qui marche pour eux. Ce n'est pas qu'une histoire de technique, il y a aussi de l'humain des gens qui préfèrent ou trouvent plus simple une façon plutôt qu'une autre. Je suis justement d'accord qu'il faut remettre en cause git-flow par exemple, parce que le meilleur workflow c'est celui qui convient à ton équipe. Il faut juste pas faire l'inverse et considérer que tout ce qui ne te correspond pas est nul et il faut (ça va avec) regarder ce qui se fait ailleurs pour ne pas retomber dans des pièges que d'autres ont rencontré.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Workflow git
Posté par barmic . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 4.
Non ou plutôt tes arguments ne suffisent pas :)
Et tu arrive à le savoir a priori ?
D’expérience, là où j'ai travaillé, personne n'était assez mature pour faire ça sans complètement exploser la complexité du code et sans se perdre dans toutes les fonctionnalités.
Ouai bof, ça n'est pas vraiment un problème. Faut rebaser fréquemment. Sur des petites équipes ça ne pose aucun problème. Ton intégration continue elle doit surtout être toujours verte, tu dois pouvoir livrer à tout moment, à la fréquence qui te semble opportune et pas à la fréquence que tu es capable de faire. Donc non tu ne peux pas accepter qu'un gars commit une erreur ou un truc qui a un effet de bord indésiré. Si tu veux, tu peux contraindre ton IC à faire un rebase fréquent (si la branche à lancer n'est pas assez à jour la passer en erreur).
Ça n'est pas une vérité générale. J'ai vu une conférence des furets. Ils n'ont pas de master et font systématiquement du big bang merge comme tu dis. Ils ont créé un outils pour ça : git-octopus.
Bof. J'ai tendance à fuir celui qui me dis de fuir. Actuellement j'ai l'impression qu'on a une explosion des workflow et c'est une très bonne chose ! Les gens font ce qui marche pour eux. Ce n'est pas qu'une histoire de technique, il y a aussi de l'humain des gens qui préfèrent ou trouvent plus simple une façon plutôt qu'une autre. Je suis justement d'accord qu'il faut remettre en cause git-flow par exemple, parce que le meilleur workflow c'est celui qui convient à ton équipe. Il faut juste pas faire l'inverse et considérer que tout ce qui ne te correspond pas est nul et il faut (ça va avec) regarder ce qui se fait ailleurs pour ne pas retomber dans des pièges que d'autres ont rencontré.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)