hello,
comment ça devrait se passer à partir de celle-ci par exemple ?
la personne qui "suit" le projet devrait recevoir une notification et pourrait décider d'un merge. Sinon toute personne qui a le droit sur le repos, sans forcément suivre le projet, peut décider le merge aussi 
Comme personne ne suit encore réellement les projets… Si y a pas de mail, ça va passer à la trappe 
J’ai validé celui là pour sûr.
MM.
Hop,
J’ai validé celui là pour sûr.
Tiens, ça me fait penser qu'on devrait peut-être passer les merges en mode rebase afin d'éviter les commits de merge et donc leur notification, cf :
Author: Gitea
New Revision: 119889
Camille, que penses-tu de faire une todo en mode wiki sur la forge ou simplement dans un pad pour consigner toutes ces remarques ? Ça t'aiderait ?
Oui on a ouvert déja un framapad.
Je cherche l’url.
Oui et non. Pour ce genre de petit merge avec un pull request "juste par précaution", c'est une bonne idée. S'il s'agit d'un merge sur un vrai devellopement fonctionnel, il faut vraiment garder l'historique de branche
https://delicious-insights.com/fr/articles/bien-utiliser-git-merge-et-rebase/
Maïeul
Re,
il faut vraiment garder l'historique de branche
Oui, c'est bien pour ça que je parlais de rebase et non de squash...
oui, mais un rebase te perd quand même l'historique de branche, tout tes
commits sont alignés, et donc tu ne sais plus que c'était une branche
différente.
Github propose le choix au moment de valider une PR, je sais pas si Gitea peut le proposer aussi ?
Salut
Sur la base de mon expérience, lorsqu'on fait un PR je trouve
préférable de préférer les merge. C'est ce qui permet de bien
identifier les apports externes et la vie associée à la PR.
Dans le cas d'un rebase on met par dessus l'historique de la PR et on
perd donc le moment où le travail de réflexion a démarré (le point de
divergence initial).
En local je préconise de travailler avec rebase. Avant de proposer un
PR, faire un rebase de la branche source permet en autre d'anticiper
les conflits de fusion.
Il y a une école du rebase par défaut sur les PR que j'appliquais au
début mais au final je trouve qu'on perd plus qu'on y gagne en terme
de suivi et de visibilité en suivant cette méthodologie.
Gitea permet de gérer le mode de fusion de la PR :
https://github.com/go-gitea/gitea/pull/3188
Km
Hop,
Salut
Sur la base de mon expérience, lorsqu'on fait un PR je trouve
préférable de préférer les merge. C'est ce qui permet de bien
identifier les apports externes et la vie associée à la PR.
Dans le cas d'un rebase on met par dessus l'historique de la PR et on
perd donc le moment où le travail de réflexion a démarré (le point de
divergence initial).
Chacun de ces modes convient à différents types de patch, amha :
- s'il n'y a qu'un seul commit dans le patch, le rebase permet d'éviter le commit de merge pour un simple patch ;
- si la branche est un gros chantier, le commit de merge semble bien adapté, et de plus parfois un squash ne fait pas de mal ça nous permet d'éviter de ramasser les oups d'un travail de longue durée.
Bref, chacun fait ce qui lui plaît, et si notre outil permet de choisir en fonction de ses préférences, c'est très bien comme ça 