Rien n’empeche de rebaser + squasher avant de merger, certes, mais c’est vachement moins relou si une machine le fait.
Le reviewer a pas besoin de demander à l’auteur de rebase + merge.
Sans compter que si t’as une activité décente sur le projet, voilà ce qu’il se passe:
- plusieurs PR creees, toutes rebasees proprement sur master,
- review d’une, et merge,
- review d’une autre et « cool, c’est bon, mais heu, tu peux rebaser steu plait? » le mec est sur un autre fuseau horaire, alors on attendra demain
- review de la suivante, et heu, tu peux rebaser steuplait?
- la deuxième a été rebasee et mergee entre temps, et paf, la troisième se tape encore un rebase. C’est sans fin.
l’alternative, c’est des historique de merde ou la moite des commits sont des merges commit, et un enfer pour celui qui fait de l’archéologie pour savoir quel commit a peter la feature x.
[^] # Re: Version communautaire limité
Posté par groumly . En réponse au journal GNOME va passer à GitLab. Évalué à 6.
Rien n’empeche de rebaser + squasher avant de merger, certes, mais c’est vachement moins relou si une machine le fait.
Le reviewer a pas besoin de demander à l’auteur de rebase + merge.
Sans compter que si t’as une activité décente sur le projet, voilà ce qu’il se passe:
- plusieurs PR creees, toutes rebasees proprement sur master,
- review d’une, et merge,
- review d’une autre et « cool, c’est bon, mais heu, tu peux rebaser steu plait? » le mec est sur un autre fuseau horaire, alors on attendra demain
- review de la suivante, et heu, tu peux rebaser steuplait?
- la deuxième a été rebasee et mergee entre temps, et paf, la troisième se tape encore un rebase. C’est sans fin.
l’alternative, c’est des historique de merde ou la moite des commits sont des merges commit, et un enfer pour celui qui fait de l’archéologie pour savoir quel commit a peter la feature x.