Git, mira múltiples twigs en el mismo repository

Aquí está nuestro process de trabajo:

  1. Los desarrolladores clonan desde un repository central.
  2. Dev A está trabajando localmente en la corrección de errores A, la twig bug_a , la inserción de la twig bug_a en el repository central.
  3. Dev B está trabajando localmente en la corrección de errores B, en la twig bug_b , en la inserción de la twig bug_b en el repository central.
  4. Cuando el trabajo finaliza, las twigs se fusionan con una twig de develop .

Supongamos (por simplicidad) que ambas twigs no tocan files comunes. Nuestro requisito es que al final se pueda rebuild exactamente qué files y códigos se cambian con bug_a . Lo mismo para bug_b . Entonces el compromiso para la fusión de bug_a en el develop muestra exactamente los cambios realizados para esta solución de error A.

Ahora surge la pregunta: estoy trabajando en bug_a y quiero ver los cambios de bug_b en mi repository.

Sé que puedo extraer los cambios de bug_b en mi bug_a branch PERO ahora mi requisito no se cumple porque en la fusión / commit final en develop también veo los cambios de bug_b y no puedo rebuild los cambios exactos realizados para resolver el error A.

Mi pregunta es ¿hay un command o procedimiento en Git donde los cambios realizados en otras twigs son visibles en la twig de trabajo local? Como una 'vista' en claro, por ejemplo

 master develop bug_b *bug_a 

Para abusar de la terminología, cada git repo es en sí mismo una vista privada muy clara: no se puede ver al otro tipo directamente. (Pero hay un atajo que mencionaré en un momento).

Afortunadamente, puede ver su indirecta, porque ustedes dos tienen un tercer repository compartido. Empuja al repository compartido, luego lo fetch (no lo hagas aún porque eso complica la respuesta) del repository compartido. Ahora puedes ver lo que hizo, porque fetch capturas (por defecto de todos modos) todo.

Aquí es donde git es muy diferente de clearcase, sin embargo: "ves lo que hizo" al pedirle a Git que lo extraiga en algún lugar visible. No se "mostrará", tienes que decir "déjame ver".

Puedes verlo haciendo uno o más de los siguientes:

  • pidiendo git (o una GUI) para mostrar diffs
  • pidiendo a git que revise una twig diferente en el tree de trabajo actual (hay un potencial obvio para colisiones aquí)
  • pidiendo a git que revise el contenido de uno o más files particulares de una twig en particular, en el tree de trabajo actual
  • pidiendo a git que revise una twig diferente en un tree de trabajo diferente (tal vez nuevo)

Todos estos requieren cierta comprensión de cómo especificar revisiones particulares (por "nombre de sucursal" o por ID de compromiso o lo que sea). Aquí hay dos cosas importantes a tener en count:

  • Cuando remotes/origin/bug_b , git crea twigs con nombres como remotes/origin/master y remotes/origin/bug_b .
  • Cuando trabajas localmente en tu repository, git crea twigs con nombres como master y bug_a .

Por lo tanto, para ver los cambios que se han obtenido en remotes/origin/bug_b , use:

 git log remotes/origin/bug_b 

Tenga en count que no necesita tener su propia twig llamada bug_b , y mucho less fusionar o extraer, o lo que sea. Solo nombre la twig remota, cuando solo quiera mirar. Solo necesita su propio nombre de twig si va a hacer su propio trabajo en una twig bug_b .

Aquí hay una parte más profunda que no necesita comprender todavía, pero debe volver a ella de vez en cuando: un nombre de twig como remotes/origin/bug_b es realmente una forma simbólica de nombrar uno de esos grandes valores de git SHA1 como ae0af6d748b98716f0f72e428728345b828c4067 . Lo que hace git cuando fetch es get todos los nuevos files y treees y todo lo demás, con todos esos commits con esos grandes ID peludos, y meterlos todos en tu repository; luego actualice las tags remotas remotes/x/y para señalar las "puntas" de cada "twig remota". Su repository tiene todo lo que todos han hecho, ahí al scope de la mano si es necesario. (A veces eso resulta "demasiado", por lo que hay forms de limitar la cantidad que realmente tiene, pero "todo" es el valor pnetworkingeterminado, y es la manera de pensar sobre ello). (En términos claros, usted tiene una copy completa de todos los VOB. Afortunadamente, git es mucho más eficiente en espacio y time que clearcase.)

Cuando haces un git pull , en realidad estás haciendo dos cosas: una git fetch -esto es lo que hace que cambien los cambios- y luego (normalmente) una git merge . La combinación combina "trabajo que hizo alguien más" con "trabajo que hiciste". No querrás eso cuando estés buscando los cambios que Bob hizo para bug_b mientras trabajabas en tu propia twig bug_a .

(Opcionalmente, puedes decirle a git que haga que git pull significa git fetch seguido de git rebase . Pero tampoco quieres eso. Solo sigue con git fetch ).

Ahora, para ese atajo: si git clone el repository compartido original, entonces tienes que esperar a que Bob bug_b sus cambios de bug_b al repository compartido, antes de que puedas verlos. Pero, si Bob le otorga acceso de lectura (mediante ssh o lo que sea) a su repository privado, puede agregar el repository de Bob como un "control remoto" alternativo. En lugar de remotes/origin/bug_b puede nombrar estos remotes/bob/ remotos remotes/bob/ por ejemplo, y hacer reference a remotes/bob/bug_b . Puede search aquellos con git remote update bob . No te molestes con todo esto a less que puedas coordinar con Bob, sin embargo. El repo compartido individual al que ambos push es generalmente el path a seguir.

Supongamos que tiene desprotegida la twig A , y desea ver los cambios realizados en la twig B Luego puede ver los cambios realizados en B con

 git log --patch B 

que le mostrará todas las confirmaciones hechas en B , junto con la diferencia de los cambios que introduce cada compromiso. Puede leer más sobre el uso de git log en los documentos de Git .

Si no tiene los últimos cambios realizados en B de su repository remoto / central en su repository local, puede git fetch <remote repo> esos cambios en su repository local, sin combinar esos cambios en A Entonces puedes ver esos cambios con

 git log --patch remoteRepo/B 

Muchos guis de Git tienen visores de diferencias visuales que puedes usar también para ver cualquier twig que desees.