Flujo de trabajo de Github preferido para actualizar una solicitud de extracción después de la revisión del código


341

Envié un cambio a un proyecto de código abierto en Github y recibí comentarios de revisión de código de uno de los miembros del equipo central.

Me gustaría actualizar el código teniendo en cuenta los comentarios de revisión y volver a enviarlo. ¿Cuál es el mejor flujo de trabajo para hacer esto? Desde mi conocimiento limitado de git / github, podría hacer lo siguiente:

  1. Actualice el código como una nueva confirmación y agregue tanto la confirmación inicial como la actualizada a mi solicitud de extracción.

  2. ¿De alguna manera (??) revierte la confirmación anterior de mi repositorio, y crea una confirmación nueva que contiene todo, y luego presenta una solicitud de extracción para eso?

  3. git committiene una función de modificación, pero he oído que no debe usarla después de haber enviado la confirmación fuera de su repositorio local. En este caso, realicé el cambio en mi PC local y me trasladé a mi rama github del proyecto. ¿Estaría bien usar 'enmendar'?

  4. ¿Algo más?

Parece que la opción 2/3 sería buena, ya que el proyecto de código abierto solo tendría una confirmación en su historia que implementaría todo, pero no estoy seguro de cómo hacerlo.

Nota: No sé si esto afecta la respuesta o no, pero no hice los cambios en una rama separada, solo hice una confirmación en la parte superior del maestro

Respuestas:


219

Simplemente agregue una nueva confirmación a la rama utilizada en la solicitud de extracción y empuje la rama a GitHub. La solicitud de extracción se actualizará automáticamente con la confirmación adicional.

# 2 y # 3 son innecesarios. Si las personas desean ver solo dónde se fusionó su rama (y no las confirmaciones adicionales), pueden usar git log --first-parentpara ver solo la confirmación de fusión en el registro.


77
masteres una rama demasiado, por lo que técnicamente no importa :)
meter

10
@OrionEdwards: como se mencionó en poke, master es una rama, por lo tanto, la actualización hará que las solicitudes de extracción basadas en él también se actualicen. (Esta es una buena razón para usar una sucursal separada para cualquier cosa para la que planee enviar una solicitud de extracción).
Ámbar

18
Dado que el código se encuentra todavía en revisión por lo general es mejor arreglar el commit (s) en lugar de introducir confirmaciones de corrección adicionales que simplemente el desorden de la historia ...
mgalgs

44
@mgalgs Eso es una cuestión de preferencia.
Ámbar

44
No me gusta esta respuesta por las razones explicadas en la publicación del blog que acabo de escribir ; Creo que la otra respuesta es mucho mejor.
Adam Spires

224

Para actualizar una solicitud de extracción

Para actualizar una solicitud de extracción (punto n. ° 1), lo único que debe hacer es retirar la misma rama de la que proviene la solicitud de extracción y presionarla nuevamente:

cd /my/fork
git checkout master
...
git commit -va -m "Correcting for PR comments"
git push

Opcional: historial de confirmación de limpieza

Es posible que se le solicite que aplaste sus confirmaciones para que el historial del repositorio esté limpio, o que desee eliminar las confirmaciones intermedias que distraen del "mensaje" en su solicitud de extracción (punto # 2). Por ejemplo, si su historial de confirmación se ve así:

$ git remote add parent git@github.com:other-user/project.git
$ git fetch parent
$ git log --oneline parent/master..master
e4e32b8 add test case as per PR comments
eccaa56 code standard fixes as per PR comments
fb30112 correct typos and fatal error
58ae094 fixing problem

Es una buena idea juntar las cosas para que aparezcan como una sola confirmación:

$ git rebase -i parent/master 

Esto le pedirá que elija cómo reescribir el historial de su solicitud de extracción, lo siguiente estará en su editor:

pick 58ae094 fixing actual problem
pick fb30112 correct typos
pick eccaa56 code standard fixes
pick e4e32b8 add test case as per PR comments

Para cualquier compromiso que desee formar parte del compromiso anterior: cambie la selección para aplastar:

pick 58ae094 fixing actual problem
squash fb30112 correct typos
squash eccaa56 code standard fixes
squash e4e32b8 add test case as per PR comments

Y cierra tu editor. Git reescribirá el historial y le pedirá que proporcione un mensaje de confirmación para la confirmación combinada. Modifique en consecuencia y su historial de confirmación ahora será conciso:

$ git log --oneline parent/master..master
9de3202 fixing actual problem

Empuja eso a tu tenedor:

$ git push -f
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (11/11), 978 bytes, done.
Total 11 (delta 9), reused 7 (delta 6)
To git@github.com:me/my-fork.git
   f1238d0..9de3202  HEAD -> master

y su solicitud de extracción contendrá una sola confirmación, incorporando todos los cambios previamente divididos en varias confirmaciones.

Cambiar la historia en repositorios públicos es algo malo

Reescribir el historial y usarlo git push -fen una rama que, potencialmente, alguien más ya ha clonado es algo malo, ya que hace que el historial del repositorio y el del proceso de pago difieran.

Sin embargo, es bueno enmendar el historial de su bifurcación para corregir el cambio que propone integrar en un repositorio. Como tal, no tenga reservas que eliminen el "ruido" de sus solicitudes de extracción.

Una nota sobre ramas

En lo anterior, muestro que la solicitud de extracción proviene de la masterrama de su bifurcación, no hay nada de malo en eso necesariamente, pero crea ciertas limitaciones, como, si esta es su técnica estándar, solo poder tener un PR abierto por repositorio . Sin embargo, es una mejor idea crear una rama para cada cambio individual que desee proponer:

$ git branch feature/new-widgets
$ git checkout feature/new-widgets
...
Hack hack hack
...
$ git push
# Now create PR from feature/new-widgets

28
+1 por mencionar cómo limpiar las confirmaciones en lugar de impulsar confirmaciones de reparación adicionales.
mgalgs

3
Me encontré con algunos problemas para recoger / aplastar y esta respuesta me ayudó. También noté que Github eliminó la conversación anterior después de que lo hice git push -f. No hubo muchos comentarios, pero eso es algo que no esperaba.
Hitesh

55
Para que quede claro, cuando se hace una nueva versión para tener un historial limpio, de hecho está cambiando sus compromisos públicos, solo está asumiendo que a nadie le importa porque es una bifurcación.
brita_

2
Seguimiento: ¿mejores prácticas cuando el maestro cambia durante su PR?
Kevin Suttle

1
Tenga en cuenta que la reescritura del historial en las solicitudes de extracción que se revisaron (o que en general tienen comentarios / códigos de referencia) podría generar confusión, ya que el historial ya no coincidirá con los comentarios a los que se referían. No hay una solución fácil: alguien cerrará el PR y lo referirá en uno nuevo (para no reescribir el historial); mi idea sería simplemente hacer una copia de seguridad del último SHA de confirmación que se está restableciendo / reescribir y referirlo en un comentario en el PR, después de que se haya realizado el empuje forzado. Si prune no elimina esa confirmación separada, su historial seguirá coincidiendo con los comentarios de PR.
Kamafeather
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.