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

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

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.

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