etiquetas - git remove tag

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

Question

He enviado un cambio a un proyecto de código abierto en Github y he recibido 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, pude hacer cualquiera de 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 (??) deshacer el compromiso anterior de mi repositorio, y crear un nuevo compromiso único que contenga todo, luego generar una solicitud de extracción para eso?

3. git commit tiene una función de enmienda, pero he oído que no debería usarla después de haber empujado la confirmación fuera de su repositorio local. En este caso, hice el cambio en mi PC local y me dirigí a mi rama Github del proyecto. ¿Estaría bien usar ''enmendar''?

4. ¿Algo más?

Parece que la opción 2/3 estaría bien, ya que el proyecto de código abierto solo tendría un compromiso en su historial 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, simplemente hice un commit encima del master

Answer 1

Para actualizar una solicitud de extracción

Para actualizar una solicitud de extracción (punto # 1), lo único que debe hacer es verificar la misma rama de la que proviene la solicitud de extracción y volver a enviarla:

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

Opcional - Limpiar el historial de compromisos

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

$ git remote add parent [email protected]: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 aplastar las cosas para que aparezcan como un solo compromiso:

$ git rebase -i parent/master

Esto le pedirá que elija cómo reescribir el historial de su solicitud de extracción, lo siguiente será 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 confirmación que desee ser parte de la confirmación anterior - cambie la selección a 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. Modifica en consecuencia y tu historial de compromiso ahora será conciso:

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

Empuje eso a su 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 [email protected]:me/my-fork.git
f1238d0..9de3202 HEAD -> master

y su solicitud de extracción contendrá un solo compromiso, incorporando todos los cambios previamente divididos en varios compromisos.

Cambiar la historia en repositorios públicos es algo malo

Reescribir el historial y usar git push -f en una rama que, potencialmente, alguien más ya ha clonado es algo malo: hace que el historial del repositorio y el de la salida divergan.

Sin embargo, es bueno que modifique el historial de su bifurcación para corregir el cambio que está proponiendo que se integre en un repositorio. Como tal, no tiene reservas que eliminen el "ruido" de sus solicitudes de extracción.

Una nota sobre las ramas.

En lo que antecede, muestro que la solicitud de extracción proviene de la rama master de su bifurcación, no hay nada de malo en eso necesariamente, pero crea ciertas limitaciones, por ejemplo, si esta es su técnica estándar, solo puedo tener un RP 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

Answer 2

Mi opinión sobre las mejores prácticas: una vez que esté listo para empaquetar una solicitud de extracción, debe obtener su propia rama de tema único, específicamente para ese propósito, desde el principio. Empiezas empujando esa rama a tu repositorio github, por ejemplo

git push origin name-of-pull-request-branch

y basando la solicitud de extracción de esa rama. Una vez hecho esto, cualquier confirmación que empuje a esa rama se agregará automáticamente a la solicitud de extracción. Usas esa rama para nada más.

Algunos prefieren que coloque el nombre de esas ramas con su ID de usuario de Github. De esa manera, pueden comprobarlo libremente a nivel local para probarlo, con beneficios como

• menos miedo a la colisión del nombre de la rama
• más fácil de recordar lo que es

Por lo general nombro mis ramas de solicitud de extracción algo así como

claybridges-do-the-things

Answer 3

Solo 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 la gente quiere ver solo dónde se fusionó su rama (y no las confirmaciones adicionales), pueden usar git log --first-parent para ver solo la confirmación de fusión en el registro.