Github Flow elimina compromiso y cambios en la historia

Estoy buscando usar el flujo de GitHub, tengo una pregunta.

Mi Repo (A, B, C, D son compromisos de fusión de la fusión en una request de extracción)

(maestro) ————- A —— B ——- C ——- D (CABEZA)

decir que lo que cometí en B tiene un defecto, pero necesito hacer una implementación que contenga C y D. ¿Cómo puedo eliminar / esconder B hasta después de la implementación y volver a colocarlo?

Con git revert B -m 1 crea una nueva confirmación que deshace los cambios que introdujo al fusionarse en la twig PR. Luego puede hacer lo mismo de nuevo, pero con la order de revertir en el command para revertir la revertir. Allí no necesita el parámetro -m 1 , ya que no se trata de ninguna fusión que revierte.

Hay un par de opciones. Sugeriría que una reversión es la mejor opción. La gente tiende a desagradar la historia resultante, pero IMO están poniendo un sentido estético por delante de las preocupaciones prácticas. Así que tienes

 A -- B -- C -- D <--(master) 

Si lo haces

 git revert B 

obtendrás

 A -- B -- C -- D -- ~B <--(master) 

que produce el mismo tree que

 A -- C -- D <--(master) 

Debes probar eso ya que es un nuevo estado del tree.

Luego, para arreglar B, volverías a crear sus cambios

 git revert ~B 

dando

 A -- B -- C -- D -- ~B -- ~~B <--(master) 

(donde ~~B realiza los mismos cambios que B ) y luego realiza las correcciones. --amend los cambios usando --amend para que termine con

 A -- B -- C -- D -- ~B -- B+ <--(master) 

(donde B+ aplica los cambios corregidos de B ).

Ahora, a algunas personas no les gusta ver los cambios B realizados, luego deshacerlos y luego volver a hacerlos. Creo que esto es un poco de arrogancia (y no del tipo útil), pero bueno, si realmente quieres, hay opciones como yo digo.

Puede optar por rebase en su lugar. Dado que esto es claramente cambios que se han llevado a cabo, tendrá que coordinar a todos los desarrolladores, ya que tendrán que realizar los pasos descritos en "recuperación de rebase cadena arriba" en la documentation de git rebase ( https: // git-scm .com / docs / git-rebase )

 git rebase --interactive A master 

Edite la list de TODO. Hay varias maneras de hacerlo, pero digamos que simplemente movemos B hasta el final, listos para recibir correcciones. Así que, literalmente, solo mueve la línea para B hasta el final de la list. Ahora tu tienes

 A -- C' -- D' -- B' <--(master) 

(donde x' es una reescritura de x que hace lo mismo pero en una "base" diferente, es decir, diferente padre).

Por supuesto que realmente quieres master^ (omitiendo B' por ahora). Mejor testing (es un nuevo estado de código). Entonces tendrás que empujar la fuerza

 git push -f master^:master 

También hay otras forms, pero estas cubren las principales opciones.