¿Qué hacer cuando el padre de la sucursal fue aplastado?

Ok, tengo branch feature/12 , está más o less hecho, así que lo ramifico y empiezo a trabajar en feature/13 , que depende de feature/12 .

La revisión del código ocurre y se hacen algunos pequeños cambios para feature/12 . Así que aplico esos cambios, luego aplasto contra master en una única function de confirmación, como es el protocolo en la empresa ( git rebase -i master ).

Ahora, de return a feature/13 , ¿cómo puedo consolidar el historial de feature/13 para que no haya conflictos de historial contra feature/12 y master ? ¿Simplemente git rebase feature / 12` y arreglo cualquier conflicto?

Sí, solo rebase contra el maestro.

Rebase intentará aplicar las confirmaciones sin aplastamiento encima de la aplastada, y es probable que vea conflictos (aunque las independientes o las últimas se reconocerán como ya aplicadas y omitidas automáticamente). Usted puede:

  • simplemente arregle el conflicto como de costumbre, lo que no debería generar cambios por etapas,
  • reconocer el antiguo commit y git rebase --skip cuando se trata, o
  • ya que está utilizando una rebase interactiva, elimine las líneas de pick de los git-rebase-todo file git-rebase-todo .

Si se siente extremadamente cauteloso y desea asegurarse de que la operación de rebase no haya agregado o eliminado accidentalmente ningún cambio que tenga en la feature/13 , puede diferenciar los difs de la versión anterior a la rebase y ahora usando un command como este inmediatamente después de terminar la operación de rebase:

 diff -u <(git diff master...feature/13@{1}) <(git diff master...feature/13) 

Esto no da salida perfectamente limpia – informará las diferencias en las líneas de context, y no sé de una mejor manera – pero definitivamente le mostrará cualquier cambio perdido (o ganado) debido a la rebase.

¿Simplemente git rebase feature/12 y soluciono algún conflicto?

Eso lo hará, pero tenga en count que los cambios adicionales en la feature/12 que se combinaron también están en el master ahora, también, y los conflictos ya se han resuelto allí. También es simplemente más limpio basar su trabajo en la versión de producción de cualquier dependencia. Si luego resulta que necesita volver a establecer la base de nuevo trabajo en la feature/12 , habría tenido que hacer eso de todos modos.