¿Debe un desarrollador de github reescribir las solicitudes de extracción del autor?

Navega tus respuestas
43

No soy un programador de profesión, pero hago algunos códigos y he usado github algunos. Me he encontrado con lo que me parece una situación sorprendente. Estoy muy familiarizado con git.

Hay un proyecto en el que encontré un error (pequeño) que me estaba afectando. Pasé una tarde encontrándolo y arreglando. Bifurqué el repositorio, confirmé el cambio y emití una solicitud de extracción. Después de ver que estaba cerrado porque "Combinado en una rama de desarrollo", pensé que todo estaba bien.

Hoy estaba navegando en el repositorio preparándome para eliminar mi sucursal, y no puedo encontrar dónde se fusionó el compromiso en el repositorio del mantenedor. Después de un tiempo, me doy cuenta de que se ha agregado como un compromiso, pero el autor ya no soy yo.

Por lo que puedo decir, la única forma de hacerlo sería utilizar específicamente una rebase, una enmienda u otra reescritura del historial para eliminar al autor original.

Esto me parece muy mal. En el mejor de los casos es confuso, en el peor de los casos, el autor de este repo está tomando el crédito por los compromisos de todos y luego se pierde la historia del colaborador original. Nuevamente es un pequeño error, no uso esto para mi currículum profesional, simplemente parece deshonesto.

¿Esto es normal? ¿Debo decir algo al respecto?

Edit: El sentimiento general parece ser que debo ir a preguntar, así que lo haré esta mañana.

Según la solicitud a continuación. Lo he comprobado y mi código existe y se aplicó exactamente como lo escribí (incluido el comentario). Verifiqué que tanto el autor como el autor han sido cambiados. También se agregó un cambio adicional al mismo tiempo que mis cambios. Es una sola línea, que afectaría tanto al parche como a otros códigos anteriores. IE la adición de una línea no está relacionada con el error que estaba solucionando.

Actualizar Parece que la respuesta fue que el autor mantiene una rama de desarrollo y no quiere fusionarse de su rama maestra en ella. Él re-escribió mi compromiso de evitar una fusión. No estaba preocupado por la rama original de b / c git lo suficientemente potente como para seleccionar, rebautizar y fusionar las confirmaciones según sea necesario.

¿Esto es típico en github?
¿Debo comunicarme con el encargado de mantenimiento de un proyecto para preguntar a qué sucursal aplicar los parches?

    
pregunta user1585512 08.08.2012 - 19:55

4 respuestas

3

Parece que la respuesta fue que el autor mantiene una rama de desarrollo y no quiere fusionarse de su rama maestra en ella. Él re-escribió mi compromiso para evitar una fusión.

    
respondido por el user1585512 10.08.2012 - 15:22
19

No, no deberían, si es evitable. Es un problema que en mi experiencia sucede con demasiada frecuencia. Sin embargo, creo que tiene más que ver con la ignorancia de cómo usar git correctamente que con alguien que quiera robar el crédito.

  • Si desean modificar su cambio antes de aplicarlo a su rama principal, pueden crear fácilmente una rama para su cambio. Luego pueden agregar su propio compromiso después del tuyo y luego fusionar la rama.
  • Si su solicitud de extracción no se basa en la última versión de su rama principal, pueden emitir un git rebase master . Si hay conflictos, pueden elegir solucionarlos por sí mismos (sin cambiar de autor) o darle la oportunidad de solucionarlos.

Creo que Github podría y debería buscar este tipo de robo de crédito accidental y educar a los mantenedores sobre las mejores prácticas cuando sea apropiado.

    
respondido por el Gerry 26.01.2013 - 18:13
6

Has omitido algunos detalles clave aquí.

  • Si la forma en que "arreglaste" el error no fue del agrado de los mantenedores, o incluso incorrecto en que introdujo sus propios errores, entonces el mantenedor podría tener Debes editar tu trabajo antes de comprometerte. En cuyo caso es comprensible cambiar el autor.

  • Como han mencionado otros, el autor es bastante diferente del interlocutor . Como usted ya sabe, el autor es el que realmente creó el commit, mientras que el committer sería quien lo aplicara.

Debería echar un vistazo de cerca al compromiso y actualizar su pregunta con sus conclusiones.

    
respondido por el Steven Penny 08.08.2012 - 21:17
3

Para responder a su pregunta actualizada:

Es difícil decir lo que es típico en github, más allá de decir que, normalmente, cada proyecto es diferente y cada uno tiene su propio flujo de trabajo preferido. En general, el mejor enfoque antes de enviar una solicitud de extracción es preguntar cuál es su flujo de trabajo o tratar de ver si se puede determinar con base en las solicitudes de extracción cerradas anteriores.

Mi experiencia personal ha sido si usted no pregunta, generalmente, en el mejor de los casos, cerrarán la solicitud de extracción sin comentarios (en el peor de los casos), o en el mejor de los casos, dejarán un comentario que explique el procedimiento que le solicita actualizar su solicitud de extracción. Diré que parece extraño la forma en que lo manejó el mantenedor en su caso, pero puede que haya sido el camino de menor resistencia para ellos. Sin embargo, dudo que estuviera intencionalmente destinado a robar crédito.

Le sugeriría que pida al mantenedor que agregue documentación que explique cómo le gustaría recibir solicitudes de extracción y contra qué sucursal evitará la confusión y falta de crédito en el futuro. Deseo que más proyectos proporcionen esta documentación, ya que creo que haría que las personas estén más inclinadas a participar en el proyecto.

    
respondido por el Jacob Schoen 10.08.2012 - 17:18

Lea otras preguntas en las etiquetas

Mantenimiento del código: ¿mantiene un patrón incorrecto al extender el nuevo código por ser consistente, o no? Escriba las variables de conversión en PHP, ¿cuál es la razón práctica para hacer esto?