Git crea una twig desde otra twig. ¿Enviar requestes de extracción para ambos?

  1. Creé una twig y envié una request de extracción de esos cambios, llamémosla twig A.
  2. Luego creé una twig B mientras aún estaba en mi twig A. Después de algunos cambios, quería enviar una request de extracción para esos cambios y vi la confirmación de la twig A (a la que envié una request de extracción) en los últimos commits de twig B.

¿Cómo debo gestionar eso?

  • ¿Puedo enviar una request de extracción para la twig B también? ¿Tendrá efectos secundarios?
  • ¿Puedo, en cambio, volver a establecer la base de las confirmaciones en la última fusión maestra y cambiar el nombre de la confirmación por el nombre de los cambios en la twig B? ¿Eso también eliminaría la confirmación en la twig A a la que envié una request de extracción?
  • Si necesito otros cambios en la twig A antes de que se acepte la request de extracción, ¿puedo todavía volver a establecer / aplastar las confirmaciones de la twig A sin afectar la twig B?

Supongo que normalmente debería asegurarme de estar nuevamente en el master antes de crear otra twig para desarrollar una nueva function para que no vuelva a suceder.

¿Puedo enviar una request de extracción para la twig B también? ¿Tendrá efectos secundarios?

Vamos a dibujar una image rápida

X --- X --- X --- X <--(master) \ A1 -- A2 <--(A) \ B1 -- B2 -- B3 <--(B) 

Supongo que el PR para A todavía es sobresaliente, por lo que A1 es una diferencia entre el master y B Si nada en B depende de A1 , esto conceptualmente no es bueno; no desea que la aprobación / fusión de B dependa de la aceptación / posible liberación prematura de los cambios en A1 .

Ahora, si se atesting el PR para A , luego de esa combinación, A1 deja de ser una diferencia; y podría argumentar "sin daño, sin falta"; pero aún sería mejor si las twigs independientes se enraizaran independientemente del master .

¿Puedo, en cambio, volver a establecer la base de las confirmaciones en la última fusión maestra y cambiar el nombre de la confirmación por el nombre de los cambios en la twig B? ¿Eso también eliminaría la confirmación en la twig A a la que envié una request de extracción?

Tomando la segunda parte de eso primero: rebasing no elimina compromisos del repository; este es un concepto erróneo (aparentemente común). Como A1 es accesible desde la twig A , no se verá afectado por una rebase de B Sin embargo, debes tener cuidado al volver a establecer bases de datos para evitar crear un duplicado de la confirmación A1 ya que esto sería contrario al propósito de la rebase.

 git rebase --onto master AB 

debería darte

  B1' -- B2' -- B3' <--(B) / X --- X --- X --- X <--(master) \ A1 -- A2 <--(A) \ B1 --- B2 --- B3 

(Tenga en count que he mostrado B1 , B2 y B3 en este diagtwig para mayor claridad para reforzar el punto de que rebasing no elimina los commits . Como no hay puntos de reference para ellos, no los verá a less que sepa cómo searchlos , y se los excluiría de push operaciones de push , etc., y eventualmente podrían get la basura recolectada. Pero justo después de la rebase, en su repository local podría hacer algo como git log B@{1} y ver que aún están ahí)

Recuerde que si alguna vez B ha sido empujado, esto puede causar problemas para otros desarrolladores (porque si bien no se eliminan las confirmaciones del repository, esto hace que las confirmaciones que solían ser alcanzables desde B ya no sean accesibles desde B , y eso no es bueno.

Consulte "Recuperación desde la database rebase" en la documentation de git rebase , y si esto no parece ser un problema, puede volver a establecer la base. Solo recuerde que necesita volver a probar el B rebasado ya que su tree está en un estado único nuevo. (La mejor práctica de IMO sería volver a probar los compromisos intermedios también).

Si necesito otros cambios en la twig A antes de que se acepte la request de extracción, ¿puedo todavía volver a establecer / aplastar las confirmaciones de la twig A sin afectar la twig B?

Hay al less un par de variaciones en esta pregunta.

Si no ha networkingistribuido B lejos de A , entonces cualquier operación de rebase que reescriba o reemplace A1 puede dejarlo en un estado inesperado, porque B seguirá señalando a través de A1 (no A1' que se creó en una rebase, o A1A2 en el caso de una calabaza, o lo que sea).

Si ha cambiado B por A , puede hacer lo que quiera con A sin ningún efecto adicional sobre B Una vez más, tenga en count los riesgos de reescribir la historia que se ha impulsado.

Finalmente, encontré otra manera que me gusta mucho, que es la selección de cerezas .

  1. Realice la request de extracción de la twig que proviene del maestro (A).
  2. Obtenga el hash de confirmación de la twig que no se basa en el maestro (B).

     git log --pretty=format:"%h - %an, %ar : %s" 
  3. (Opcional) Elimine la twig anterior (B) si desea mantener el mismo nombre:

     git branch -DB 
  4. Crea una nueva twig desde el maestro:

     git checkout -b B 
  5. Cherry elige los cambios (fusiona los cambios en la nueva twig):

     git cherry-pick HASH_OF_B (noted in step 2) 
  6. Combina si tienes conflictos, luego termina con la selección inteligente:

     git cherry-pick --continue 
  7. Envíe una request de extracción para esta nueva sucursal basada correctamente en el maestro.

Lo que me gusta de esto es que la twig principal se mantiene en forma perfecta (perfectamente limpia) y es muy simple de hacer. También podemos aplastar los commits en las twigs sin preocuparnos.