¿Es correcto pedirles a los contribuyentes que vuelvan a redactar sus solicitudes de extracción en github?

Mantengo un repositorio de github relativamente popular.

Cuando una solicitud de extracción es buena para fusionar, generalmente le pido al autor que la cambie a una sola confirmación antes de fusionarla (especialmente cuando ha habido varias ediciones pequeñas).

¿Es esta una buena práctica de git? ¿Es esta la etiqueta GitHub aceptable / estándar?

Entonces algunos beneficios:

Me sale un buen historial de confirmación limpio en los registros de confirmación
No necesito alterar el compromiso yo mismo
Delega parte del trabajo.

Algunos posibles inconvenientes:

No estoy seguro si esto es buena etiqueta
No estoy seguro de si esta es una buena práctica de git
Por lo general, ya he pedido algunos otros cambios, este es uno más y no quiero desanimar a los contribuyentes.

github etiquette

— Pablojim
fuente

¿Puede describir algunos beneficios y desventajas que ve al hacer el proceso de esta manera?

— Alex Feinman

Algunos beneficios y desventajas adicionales que vale la pena considerar. bueno: git-bisect y otras reversiones son más fáciles cuando cada commit produce un estado edificable o completo, y este enfoque es una forma simple de garantizarlo. malo: pequeños cambios con mensajes de confirmación simples se convierten en mega confirmaciones. Por ejemplo, "Cambió esta línea para arreglar el caso de la esquina de manera regular" podría incluirse en "Agregar función para, gran lista de cambios ". Esto hace que encontrar el motivo de un cambio específico sea un poco más difícil.

— Gankro

No hay nada malo en establecer estándares. Simplemente deje claro por adelantado lo que se espera. Ejemplo: symfony.com/doc/current/contributing/code/patches.html Desplácese hacia abajo hasta el Paso 3:

— envíe

@Granko: "Rebase" y "rebase en un solo commit" son dos cuestiones separadas.

— Matthew Scharley

Si se le pide a un contribuyente que haga esto, ¿debería sobrescribir la rama de la solicitud de extracción con git push -f?

— Flimm

En lo que respecta a Git, es algo así como una guerra santa si simplemente debes fusionar ramas o rebasar los commits en la última versión de la rama en la que te estás fusionando. Hay muchas conversaciones sobre cuál es mejor si haces una búsqueda rápida en Programmers.SE .

En cuanto a la etiqueta detrás de esto, tratemos esto desde una perspectiva práctica. Cuando se trata de código nuevo que viene de otra persona, siempre es mejor hacer que fusionen los últimos cambios de la rama o que lo vuelvan a crear antes de fusionarlo para garantizar una fusión limpia. Recuerde, escribieron el código, por lo que generalmente son, con mucho, los más calificados para lidiar con cualquier conflicto de fusión / rebase. Personalmente no veo ningún problema con eso, y veo esta solicitud todo el tiempo de otras personas. Para mí, si no hay conflictos, a menudo lo haré yo mismo, ya que es una actualización de dos segundos que git puede aplicarse. Pero si hay conflictos, siempre le pediré al autor original del código que se encargue de ello.

Además, para GitHub (como mínimo) específicamente, mostrarán un enlace a su CONTRIBUTINGarchivo sobre cualquier intento de relaciones públicas, por lo que es un buen lugar para delinear sus expectativas y muchos proyectos incluyen que solo fusionarán ramas actualizadas.

— Matthew Scharley
fuente

+1 por traer el pragmatismo a la discusión. Sí, de eso se trata. Puede ser bastante difícil resolver conflictos complejos en grandes solicitudes de extracción, especialmente cuando se trata de un cierto número de confirmaciones. Ese es el punto en el que se debe pedir al autor original que intervenga. Los conflictos fáciles no son el problema, nunca lo fueron y nunca lo serán.

— JensG

¡+1 por proporcionar una respuesta y no solo comentarios!

— Pablojim