Des gens qui écrivent de mauvais messages de commits ça existait déjà avant que git existe, reprocher ça a github me semble très osé.
Tu reproche de ne pas savoir correctement utiliser les outils à disposition pour faire des revues. Le github flow est le seul flow connu est un peu populaire (donc médiatisé, connu, repris, décris, documenté largement,...) qui intègre la notion de revue. Les forges avant github étaient rare à avoir un outil de revue intégré.1
git est un outil mal compris, mais je ne suis absolument pas certain que laisser les gens utiliser git sans leur donner un cadre aurait donné de meilleurs résultats. Est-ce que le github flow est le meilleur cadre ? J'en doute, mais aucun autre n'a pu avoir la même popularité.
Entre autres conséquences, ça produit des pull requests de plus en plus difficiles à évaluer, vu qu’on ne peut plus étudier les changements commits par commits, il faut nécessairement étudier le diff sur la pull request complète. Évidemment, c’est beaucoup plus ardu (surtout quand, comme au-dessus, on ne sait pas faire un check out local). Et ça donne lieu à des fils Twitter lunaires comme celui-ci, où certaines réponses me donnent envie de me taper la tête contre le mur en hurlant « mais apprenez à utiliser git bordel ! »
Moi tu vois j'y vois un problème2 bien plus vieux que git et qui est une pratique largement répandue même hors github : beaucoup trop de choses dans une branche. Pour moi et dans l'équipe où je suis on préfère merger rapidement, faire ce que l'on appel de l'intégration continue (pas dans le sens utiliser un outil d'intégration continue, mais intégrer de manière continue notre code). Si vous passer votre temps à refactorer des pans important du code et/ou modifier de grandes partie sans pouvoir merger sans backtrack, c'est dommage (amha il faut se poser des questions), mais ce n'est sans doute pas fait pour vous, par contre si vous pouvez le mettre en place ça permet de faire des revues infiniment plus petites tout en simplifiant beaucoup le travail collaboratif.
D'ailleurs tes critiques sont toujours valides sur gitlab qui est l'outil utilisé par ceux qui critique github dans ce thread... ↩
Attention je ne dis pas que c'est un problème en soit et que tout le monde devrait faire d'une façon ou d'une autre, mais il le twitt présente ce qui pour son auteur est un problème. ↩
[^] # Re: Resume-driven development ?
Posté par barmic 🦦 . En réponse au journal Doctoshotgun pris d'assaut par le variant étudiant. Évalué à 2.
Ton reproche ne s'adresse pas au github flow.
Des gens qui écrivent de mauvais messages de commits ça existait déjà avant que git existe, reprocher ça a github me semble très osé.
Tu reproche de ne pas savoir correctement utiliser les outils à disposition pour faire des revues. Le github flow est le seul flow connu est un peu populaire (donc médiatisé, connu, repris, décris, documenté largement,...) qui intègre la notion de revue. Les forges avant github étaient rare à avoir un outil de revue intégré.1
git est un outil mal compris, mais je ne suis absolument pas certain que laisser les gens utiliser git sans leur donner un cadre aurait donné de meilleurs résultats. Est-ce que le github flow est le meilleur cadre ? J'en doute, mais aucun autre n'a pu avoir la même popularité.
Moi tu vois j'y vois un problème2 bien plus vieux que git et qui est une pratique largement répandue même hors github : beaucoup trop de choses dans une branche. Pour moi et dans l'équipe où je suis on préfère merger rapidement, faire ce que l'on appel de l'intégration continue (pas dans le sens utiliser un outil d'intégration continue, mais intégrer de manière continue notre code). Si vous passer votre temps à refactorer des pans important du code et/ou modifier de grandes partie sans pouvoir merger sans backtrack, c'est dommage (amha il faut se poser des questions), mais ce n'est sans doute pas fait pour vous, par contre si vous pouvez le mettre en place ça permet de faire des revues infiniment plus petites tout en simplifiant beaucoup le travail collaboratif.
D'ailleurs tes critiques sont toujours valides sur gitlab qui est l'outil utilisé par ceux qui critique github dans ce thread... ↩
Attention je ne dis pas que c'est un problème en soit et que tout le monde devrait faire d'une façon ou d'une autre, mais il le twitt présente ce qui pour son auteur est un problème. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll