2012-10-01 90 views
60
  • me hizo algunos cambios
  • presenté una solicitud de extracción
  • La solicitud de extracción fue aceptada y se fusionaron.
  • Encontramos un error
  • Los cambios se eliminaron nuevamente mientras solucionaba el error.

He solucionado el error y deseo volver a enviar la solicitud de extracción con 1 confirmación adicional. ¿Hay alguna forma de volver a abrir la solicitud de extracción o actualizarla, o tengo que crear una nueva solicitud de extracción, escribir la descripción, etc. de nuevo? Gitorious tiene esta característica y recientemente nos hemos mudado a GitHub.GitHub: La reapertura de una solicitud de extracción fusionada

+0

Estaba en una situación similar en la actualidad, es decir, utilicé el botón "Merge Pull Request", que por defecto fusiona los cambios en la rama de destino y cierra el PR. Más tarde descubrí un error en las pruebas que quería que el desarrollador original solucionara. Quería una forma de reabrir este PR para que se puedan agregar más commits a este mismo PR pero no podría, ya que no hay un botón para reabrir el PR. – SBirthare

Respuesta

70

La respuesta parece ser: No se puede.

Una vez que una solicitud de extracción se combina y se cierra, se bloquea para siempre y no se puede volver a abrir. Si su solicitud de extracción está fusionada, cerrada, sus cambios se retiran (mediante la fuerza empujando hacia atrás hasta antes de la fusión), necesitará agregar confirmaciones a la sucursal y crear una nueva solicitud de extracción, copiar todos los detalles y probablemente proporcionar un enlace a la solicitud de extracción original para guardar el historial manualmente.

Puede ser una buena función para futuras GitHub.

+7

No sé cuándo se modificó, pero ahora puedes comentar y reabrir las relaciones públicas cerradas. –

+10

@LB, no parece que pueda volver a abrir las publicaciones públicas que se hayan cerrado * y fusionado *. –

+0

Realmente puedes. Suponiendo que ha revertido la fusión inicial, puede hacer una rama del repositorio principal, y en esta nueva rama solo revertir la confirmación que revertía la fusión. – SsjCosty

12

que reabrió con éxito una solicitud de extracción por

  1. Al comentar sobre la solicitud de extracción
  2. Al hacer clic en el botón 'Enviar y volver a abrir', que apareció en el formulario de comentarios.
+0

No he logrado replicar esto. ¿Puede explicar los pasos necesarios para ver este comportamiento? Traté de comentar sobre una solicitud de extracción cerrada (no funcionó), comentando sobre una solicitud de extracción cerrada y presionando a la sucursal que estaba ingresando (no funcionó). ¿Algo más para probar? ¿Se requiere que la solicitud de extracción se fusione y luego se la elimine de alguna manera? –

+0

No sé cuál es el requisito oculto que hace la diferencia. Podría ser cualquiera de (he enviado nuevos cambios para la solicitud de extracción, soy miembro de los propietarios del proyecto, otros ...) –

+0

Ahora probé todo lo que mencionaste, todavía no puedo verlo. Soy el propietario del repositorio. La búsqueda en Google de "Enviar y volver a abrir GitHub" proporciona un solo hit: esta página. Cualquier información adicional sería extremadamente útil. ¿Tu pedido de extracción fue inicialmente denegado? –

3

Solo obtenga una nueva sucursal de la sucursal existente donde ha realizado 1 compromiso adicional. A partir de ahí, envíe la solicitud de extracción.

+1

Eso daría como resultado una nueva solicitud de extracción sin historial para el original. – Dave

+1

Esto es lo que terminé haciendo. Sí, la historia es menos lineal, pero está bien para mí. – possen

3

Usted puede utilizar la acción de reversión:

enter image description here

Se va a crear otra solicitud de extracción deshacer todos los cambios que hicieron en el PR fusionada.

+0

Esta no es la mejor práctica :) – antonbormotov

+0

@antonbormotov ¿Puedes sugerir un enfoque mejor? –

+0

Supongamos que hemos combinado pr con commits (mA y mB) en la rama estable que queremos revertir. Después de fusionar "revertir" pr, el historial se verá como el árbol de confirmaciones: X-Y-mA-mB-C-D-rA-rB-E-F. ¿Por qué quiere ver todos estos commits en la historia, que aplican cambios (mA, mB) y luego los cancelan (rA, rB)? Sería mejor volver a establecer la base y eliminar esos "malos" commits mA y mB de la rama estable y mantener limpio el historial. Por supuesto, tiene sentido si la fusión fue relativamente reciente. – antonbormotov

Cuestiones relacionadas