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

25

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
1
¿Puede describir algunos beneficios y desventajas que ve al hacer el proceso de esta manera?
Alex Feinman
1
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
1
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
66
@Granko: "Rebase" y "rebase en un solo commit" son dos cuestiones separadas.
Matthew Scharley
2
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

Respuestas:

16

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
¡+1 por proporcionar una respuesta y no solo comentarios!
Pablojim