J’ai un avis mitigé sur cet article.
Le contenu est correct, aucun problème avec ça, mais ça décrit une méthode parmi tant d’autres…
Tout le monde n’est pas forcément d’accord, ce n’est pas forcément applicable à tous les projets, ça décrit plus une possibilité de workflow complet pour un projet particulier qu’une “procédure de merge request” générique comme le laisse entendre le titre.
Il manque une précision selon moi, pour dire que c’est “juste un exemple”, chaque élément décrit correspondant à une décision à prendre par les mainteneurs de chaque projet (convention de nommage des branches, langue utilisée, template de description de MR, etc.).
Cela étant dit, je suis quand même heureux de l’avoir lu, et je remercie l’auteur de partager ses connaissances/méthodes/habitudes ;)
PS: Une petite imprécision quand même, main n’est pas juste le nom de la branche principale sur GitHub, cette modification a aussi été appliquée sur GitLab (depuis la version 14.0), et pourrait potentiellement être appliquée un jour au niveau de git lui même (si ce n’est pas déjà fait, mais j’ai l’impression que non).
C’est toujours mieux d’avoir un exemple pour comprendre une technique j’imagine.
Mais chaque partie est indépendante et n’est pas obligatoire bien sûr, ce sont des recommandations en réalité, adaptable en fonction du sujet.
J’ai rectifié pour la partie branch main, je te remercie :)
La peinture semble encore très fraîche, je vois un gros batch d’articles il y a 5 jours. Bonne chance @Mediashare c’est une bonne idée de proposer plusieurs canaux pour partager des informations.
J’ai un avis mitigé sur cet article. Le contenu est correct, aucun problème avec ça, mais ça décrit une méthode parmi tant d’autres…
Tout le monde n’est pas forcément d’accord, ce n’est pas forcément applicable à tous les projets, ça décrit plus une possibilité de workflow complet pour un projet particulier qu’une “procédure de merge request” générique comme le laisse entendre le titre.
Il manque une précision selon moi, pour dire que c’est “juste un exemple”, chaque élément décrit correspondant à une décision à prendre par les mainteneurs de chaque projet (convention de nommage des branches, langue utilisée, template de description de MR, etc.).
Cela étant dit, je suis quand même heureux de l’avoir lu, et je remercie l’auteur de partager ses connaissances/méthodes/habitudes ;)
PS: Une petite imprécision quand même,
main
n’est pas juste le nom de la branche principale sur GitHub, cette modification a aussi été appliquée sur GitLab (depuis la version 14.0), et pourrait potentiellement être appliquée un jour au niveau de git lui même (si ce n’est pas déjà fait, mais j’ai l’impression que non).C’est toujours mieux d’avoir un exemple pour comprendre une technique j’imagine. Mais chaque partie est indépendante et n’est pas obligatoire bien sûr, ce sont des recommandations en réalité, adaptable en fonction du sujet.
J’ai rectifié pour la partie branch
main
, je te remercie :)