Corregir una mala request de extracción

Bifurqué el informe maestro de un amigo, realicé algunas confirmaciones y luego hice una request de extracción.

Hubo una serie de problemas con mi request:

Uno, el estilo de confirmación fue incorrecto.

Dos, parte del código era malo.

Tres, aparentemente necesito hacer una rebase de la request de extracción en lugar de una combinación.

He arreglado todo el código, pero tengo miedo de enviarlo a mi sucursal; ¿Necesito forzarlo o algo así? Además, ¿cómo soluciono los otros problemas?

El RP en cuestión: https://github.com/jleclanche/fireplace/pull/344

daniel.bak@STPC039 ~/documents/github/fireplace (master) $ git rebase jleclanche/master First, rewinding head to replay your work on top of it... Applying: Corrupted Healbot + test Applying: Implemented Bilefine Tidehunter & Zealous Initiat Applying: Fixing Zealous Initiate name Applying: Corrupted Seer Applying: Implement Shadow Strike daniel.bak@STPC039 ~/documents/github/fireplace (master) $ git rebase -i jleclance/master fatal: Needed a single revision invalid upstream jleclance/master daniel.bak@STPC039 ~/documents/github/fireplace (master) $ git rebase -i jleclance/master fatal: Needed a single revision invalid upstream jleclance/master daniel.bak@STPC039 ~/documents/github/fireplace (master) 

Más:

 daniel.bak@STPC039 ~/documents/github/fireplace (master) $ git log jleclanche/master commit 644c375b065c10edd02b8ba2450842404971919a Author: Jerome Leclanche <jerome@leclan.ch> Date: Fri Apr 29 14:26:39 2016 +0300 Implement Silithid Swarmer, with tests commit 1f33e4888cdbdec159e932ab4259b9e4f015adc8 Author: Jerome Leclanche <jerome@leclan.ch> Date: Fri Apr 29 13:20:57 2016 +0300 Add a NUM_ATTACKS_THIS_TURN attribute selector commit 13b58c2ee4249c4195416d257213cf1c4e0a276c daniel.bak@STPC039 ~/documents/github/fireplace (master) : Implement buff-based enrage from 12051 commit 72b95d2bff4c1af5b2be0331ce6c8b2266298d52 Author: Jerome Leclanche <jerome@leclan.ch> Date: Tue Apr 26 06:53:49 2016 +0300 Add tests for Dalaran Aspirant 

A less que el proyecto tenga algunos requisitos adicionales, y muchos de ellos lo hagan, si necesita corregir un error de encoding en su PR, todo lo que debe hacer es comprometerse y enviar los cambios a su sucursal existente. Deben aparecer como actualizaciones en la request de extracción.

Aquí hay un ejemplo de una request de extracción que necesitó algunas correcciones . Puede ver mi comentario en línea sobre la request de extracción inicial (aplanada en la request de extracción) y la actualización del remitente original se compromete.

Tu caso es diferente. Tienen dos problemas con tu compromiso y ambos son selects puntillosas de estilo Git.

El primero es que no quieren ver ninguna fusión en su RP. Tu historia se ve así:

 1 - 2 - 3 - 4 - 5 - 6 [jleclanche/master] \ \ A - B - C - D - E - F [feature/wog_cards] 

Tener fusiones en medio de sucursales puede dificultar la comprensión de la historia en proyectos grandes con muchas contribuciones. Quieren que rehagas toda la twig como si todo estuviera hecho además de la última confirmación.

 1 - 2 - 3 - 4 - 5 - 6 [jleclanche/master] \ A - B - C - D - E - F [feature/wog_cards] 

Afortunadamente, Git puede hacer esto por ti. Primero, asegúrate de que el jleclanche remoto de jleclanche esté actualizado con una búsqueda. A continuación, feature/wog_cards pago feature/wog_cards (o como se llame a su bifurcación) y ejecute git rebase jleclanche/master .

  • git fetch jleclanche
  • git checkout feature/wog_cards
  • git rebase jleclanche/master

Esto repatch cada cambio en su twig encima de jleclanche/master . Puede haber conflictos, resolverlos como es normal y seguir las instrucciones que Git te brinda (es decir, usar git rebase --continue ).

Una vez hecho esto, también puede usar rebase para corregir sus posts de compromiso y seguir su guía de estilo. Esta vez es una database interactiva. Esto le permite editar sus commits. Desde tu bifurcación ejecuta git rebase -i jleclanche/master . Aparecerá un editor con instrucciones. Desea utilizar la opción "volver a networkingactar" en cada confirmación. Git te presentará con cada post de compromiso a la vez y deberás editarlos para seguir su guía de estilo .

Aquí hay más información sobre cómo reescribir el historial .

Finalmente, necesitas impulsar estos cambios. Debido a que ha cambiado el historial, sus cambios no pueden completarse sin problemas con sus confirmaciones existentes. Entonces debes forzar el empuje. En este caso, está bien, el único depósito que puedes estropear es el tuyo. git push --force origin . Entonces sus cambios deberían aparecer en el PR.

Como puede ver, esto implica un conocimiento bastante avanzado de Git. El proyecto debe encargarse de las soluciones de custodia de la OMI a las contribuciones de los contribuyentes por primera vez.

Después de que haya arreglado su sucursal local para tener el historial que desea, simplemente presione forzar a la sucursal de PR y el PR se actualizará automáticamente con las confirmaciones reemplazadas.