¿Cómo trabajar con un repository remoto que contiene muchas twigs?

Supongamos que un repository remoto (central) tiene varias twigs y al principio tengo localmente la copy exacta del repository remoto.

Ahora quiero cambiar algo en una de las twigs en el repository remoto. Podría hacer algunos cambios en la copy local de la twig remota y luego intentar presionarla, pero supongo que en este caso puedo tener un conflicto de fusión que será difícil de resolver. Entonces, creo que uno tiene que hacer lo siguiente:

  1. Cree una copy local (twig C ) de la copy local (twig B ) de la twig remota (twig A ).
  2. Haga cambios a esta "copy de la copy" (twig C ).
  3. Tire de la twig remota nuevamente (twig A ). Actualizará la copy local del repository remoto (twig B ).
  4. Combine localmente la "copy de la copy" (twig C , que contiene sus cambios) en la copy local (actualizada) (twig B ) del repository remoto (twig A , que contiene los cambios realizados por otros).
  5. Ahora puede enviar la copy local del repository remoto (twig B ) (que contiene los cambios y cambios de otros) a la twig remota ( A ).

Supongo que mi descripción puede ser confusa. Entonces, trato de resumirlo con diferentes palabras: copie A en B , copie B en C , modifique C , actualice B usando el nuevo estado de A (básicamente copie A en B nuevo), combine C en B , presione B en A .

¿Es el path a seguir?

Un flujo de trabajo muy común en Git para trabajar con una twig compartida (es decir, una twig que varios ingenieros pueden estar modificando al mismo time / casi al mismo time) es la siguiente:

 git pull origin the_branch # work work work git push origin the_branch 

Como señaló correctamente, es posible que encuentre un problema cuando vaya a presionar, porque en el momento en que empuja, otras personas pueden haber empujado otras confirmaciones sobre la the_branch . Aquí hay dos enfoques básicos a su scope. En primer lugar, puede tirar fusionar el control remoto the_branch en su sucursal local, y luego expulsar:

 git pull origin the_branch # possibly resolve merge conflicts, then make a merge commit git push origin the_branch 

Este enfoque crearía un compromiso de fusión en su sucursal local, y ese compromiso típicamente podría aparecer también como parte del historial de la sucursal remota. Si no te gustan los commit de fusión, entonces el rebase es otra opción aquí:

 git pull --rebase origin the_branch # again, possibly resolve merge conflicts git push origin the_branch 

Si vas a la opción de rebase, estarías depositando tus compromisos directamente en la parte superior de la twig remota, como si tu sucursal local ya tuviese las confirmaciones hechas recientemente por otras personas.

Hay un caso de borde persistente con cualquier enfoque. ¿Qué sucede si aparece un nuevo material entre el momento de su fusión / rebase y el momento en que va a presionar? Si eso sucediera, entonces tendrías que unir / rebase nuevamente. Pero en mi experiencia, esto casi nunca sucede, y en realidad ni siquiera puedo recordar que esto me haya pasado una vez.

Lo que usted describe es una práctica de desarrollo estándar: las sucursales locales y remotas usualmente tienen el mismo compromiso (ayb en su caso), y el desarrollo se realiza en una tercera sucursal C.

Antes de empujar hacia el control remoto, tire, y luego rebase (esto generalmente se prefiere a una combinación) C sobre el resultado y empuje hacia atrás.

Esta es la opción más segura de la OMI, y una buena práctica.