Est-il correct de demander aux contributeurs de rebaser leurs demandes de pull sur github

Je maintiens un dépôt github relativement populaire.

Lorsqu'une demande de tirage est bonne à fusionner, je demande généralement à l'auteur de la rebaser en un seul commit avant de la fusionner (en particulier lorsqu'il y a eu plusieurs petites modifications).

Est-ce une bonne pratique git? Cette étiquette GitHub est-elle acceptable / standard?

Donc, quelques avantages:

J'obtiens un joli historique de commit propre dans les logs de commit
Je n'ai pas besoin de modifier le commit moi-même
Il délègue une partie du travail

Quelques inconvénients possibles:

Je ne sais pas si c'est une bonne étiquette
Je ne sais pas si c'est une bonne pratique git
J'ai généralement déjà demandé quelques autres changements - c'est un de plus et je ne veux pas décourager les contributeurs.

github etiquette

— Pablojim
source

Pouvez-vous décrire certains avantages et inconvénients que vous voyez en procédant ainsi?

— Alex Feinman

Certains avantages et inconvénients supplémentaires méritent d'être examinés. bon: git-bissect et autres inversions sont plus faciles lorsque chaque commit produit un état constructible ou autrement complet, et cette approche est un moyen simple de le garantir. mauvais: les petits changements avec de simples messages de commit sont roulés en méga commits. EG "La modification de cette ligne pour corriger le cas de coin tel ou tel" pourrait être intégrée dans "Ajouter une fonctionnalité foo, une grande liste de changements ". Cela rend un peu plus difficile de trouver la raison d'un changement spécifique.

— Gankro

Rien de mal à fixer des normes. Il suffit de préciser clairement ce qui est attendu. Exemple: symfony.com/doc/current/contributing/code/patches.html Faites défiler jusqu'à l'étape 3: Soumettez votre patch

— Cerad

@Granko: "Rebase" et "rebase in a single commit" sont deux problèmes distincts.

— Matthew Scharley

Si un contributeur est invité à le faire, doit-il remplacer la branche de la demande d'extraction par git push -f?

— Flimm

En ce qui concerne Git, c'est une sorte de guerre sainte, que vous deviez simplement fusionner les branches ou rebaser les commits sur la dernière version de la branche dans laquelle vous fusionnez. Il y a beaucoup de conversations sur ce qui est mieux si vous effectuez une recherche rapide sur Programmers.SE .

Quant à l'étiquette derrière cela, permet de traiter cela d'un point de vue pratique. Lorsque vous traitez un nouveau code provenant de quelqu'un d'autre, il est toujours préférable de le faire fusionner les dernières modifications de la branche ou le rebaser avant de le fusionner pour garantir une fusion nette. N'oubliez pas qu'ils ont écrit le code, ils sont donc généralement de loin les plus qualifiés pour gérer les conflits de fusion / rebase. Personnellement, je ne vois pas de problème avec cela, et je vois cette demande tout le temps d'autres personnes. Pour moi, s'il n'y a pas de conflits, je le ferai souvent moi-même car c'est une mise à jour de deux secondes que git peut appliquer lui-même. Mais s'il y a des conflits, je demanderai toujours à l'auteur d'origine du code de s'en occuper lui-même.

En outre, pour GitHub (au minimum) en particulier, ils afficheront un lien vers votre CONTRIBUTINGfichier au-dessus de toutes les tentatives de relations publiques, ce qui constitue un bon endroit pour décrire vos attentes et de nombreux projets incluent qu'ils ne fusionneront que les branches à jour.

— Matthew Scharley
source

+1 pour avoir introduit le pragmatisme dans la discussion. Oui, c'est tout l'intérêt. Il peut être assez difficile de résoudre des conflits complexes dans de grandes demandes de tirage, en particulier lorsqu'un certain nombre de validations sont impliquées. C'est le point où l'auteur original devrait être invité à sonner. Les conflits faciles ne sont pas le problème, ils n'ont jamais été et ne le seront jamais.

— JensG

+1 pour avoir fourni une réponse et pas seulement des commentaires!

— Pablojim