il a grandement popularisé son propre workflow associé
Dommage que le deuxième point annule presque complètement le premier...
La plupart des gens avec qui je travaille aujourd’hui en bioinformatique savent bien utiliser GitHub mais certainement pas git.
Récemment j’ai expliqué à quelqu’un comment on pouvait étudier localement les conséquences d’une pull request en faisant un check out de la branche correspondante dans sa copie de travail. Ça faisait des années que le type utilisait GitHub, il n’avait pas la moindre idée qu’on pouvait faire ça. Pour lui tout ce qu’on pouvait faire avec une pull request c’était étudier les diffs tels qu’affichés sur GitHub, puis cliquer sur le bouton « merge » si on est satisfait.
Autre truc rigolo : globalement, les pull requests ont remplacé les commits comme unité de base du développement. Les commits ne servent plus à rien, ils n’ont plus aucune logique, plus aucune cohérence, et les messages associés sont complètement non-informatifs (« more work on foo.py », « update makefile », « last changes », voire même simplement « WIP » — work in progress). C’est désormais dans les messages associés aux pull requests que les développeurs expliquent ce qu’ils font, c’est là qu’il faut aller chercher si on veut comprendre l’évolution d’un projet.
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 ! »
[^] # Re: Resume-driven development ?
Posté par gouttegd . En réponse au journal Doctoshotgun pris d'assaut par le variant étudiant. Évalué à 10.
Dommage que le deuxième point annule presque complètement le premier...
La plupart des gens avec qui je travaille aujourd’hui en bioinformatique savent bien utiliser GitHub mais certainement pas git.
Récemment j’ai expliqué à quelqu’un comment on pouvait étudier localement les conséquences d’une pull request en faisant un check out de la branche correspondante dans sa copie de travail. Ça faisait des années que le type utilisait GitHub, il n’avait pas la moindre idée qu’on pouvait faire ça. Pour lui tout ce qu’on pouvait faire avec une pull request c’était étudier les diffs tels qu’affichés sur GitHub, puis cliquer sur le bouton « merge » si on est satisfait.
Autre truc rigolo : globalement, les pull requests ont remplacé les commits comme unité de base du développement. Les commits ne servent plus à rien, ils n’ont plus aucune logique, plus aucune cohérence, et les messages associés sont complètement non-informatifs (« more work on foo.py », « update makefile », « last changes », voire même simplement « WIP » — work in progress). C’est désormais dans les messages associés aux pull requests que les développeurs expliquent ce qu’ils font, c’est là qu’il faut aller chercher si on veut comprendre l’évolution d’un projet.
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 ! »
/rant