En Git, las sucursales locales pueden rastrearse entre sí, ¿cómo es esto útil?

Escuché que en Git , puedes dejar que una local branch A rastree otra local branch B

¿Por qué alguien querría hacer eso?

Las principales cosas que me vienen a la mente para hacer que una sucursal local rastree otra sucursal local son (1) posts más informados de Git sobre una sucursal que se adelanta / detrás de la sucursal rastreada y (2) anzuelos de activación.

Un área en la que Git muestra más información es cuando se crea una sucursal. La creación de una twig básica tiene el siguiente aspecto:

 $ git co -b A master Switched to a new branch 'A' 

Al crear una twig de seguimiento se ve así:

 $ git co --track -b B master Branch B set up to track local branch master. Switched to a new branch 'B' 

Esto agregaría lo siguiente en .git/config :

 [branch "B"] remote = . merge = refs/heads/master 

Después de realizar algunos cambios en las twigs A y B , la ejecución git status -s -b en la twig A muestra ## A mientras que en la twig B se muestra ## B...master [ahead 1, behind 1] , proporcionando información rápida sobre la relación entre las twigs B y el master .

La otra área donde puede desear que una twig local rastree otra sucursal local es activar ganchos ; en particular pre-receive , update , post-receive y post-update durante un git push . Es posible que tenga ganchos para, por ejemplo, activar una compilation en un server de continuous integration, hacer algunas comprobaciones de encabezado de licencia, verificar errores de formatting de espacio en blanco, etc.

Un ejemplo en el que puedo pensar es si tienes una twig 'estable'. Entonces sería bueno si pudieras crear una nueva twig, "experimentar" por ejemplo, y dejar que rastreara la twig estable.

 git checkout --track -b experiment stable * do some experiments with some commits * git push 

Aparte de eso, podría ser por coinheritance (eso es solo una suposition).

Tenga en count que la información anterior / posterior que tiene entre una twig ' B ' y otra ' A ' rastreada por la primera solo funciona si la configuration de branch.B.merge está estrictamente definida: refs/heads/master .
No funcionaría si está vagamente definido: ' master '.

Pero con commit 05e7368 , hecho por Junio ​​C Hamano ( gitster ) para Git 2.3.0 (Q1 2015), esto también funcionará.

Al verificar una sucursal que está configurada para build sobre otra sucursal (a menudo, una sucursal de seguimiento remoto), " git checkout " informa cómo se relaciona su trabajo con la otra sucursal, por ej.

 Your branch is behind 'origin/master', and can be fast-forwarded. 

Cuando se introdujo esta function, esto solo se hacía para las sucursales que se basan en twigs de seguimiento remoto, pero 5e6e2b4 (Hace que las sucursales locales se comporten como sucursales remotas cuando --tracked , 2009-04-01, git 1.6.3) agregó soporte a brinde el mismo informe para las sucursales que se basan en otras sucursales locales (es decir, sucursales cuya branch.*.remote variables branch.*.remote están configuradas en ' . ').
Sin embargo, a diferencia del soporte para las sucursales que se basan en twigs de rastreo remoto, esto no tomó en count el hecho de que la configuration de branch.*.merge puede registrar un nombre de twig abreviado .

Cuando branch.*.merge se establece en ' master ' (no en ' refs/heads/master '), es decir, "mi branch se basa en la twig local 'master'", esto provocó que " git checkout " informara:

 Your branch is based on 'master', but the upstream is gone. 

El upstream es nuestro repository y definitivamente no se ha ido, por lo que esta salida no tiene sentido.

Hay muchas ocasiones en las que es útil rastrear otra sucursal local. Por ejemplo, en algunos flujos de trabajo de git, hay algo en el lugar que protege al maestro para que no reciba directamente requestes de inserción. Un ejemplo es un sistema de revisión de código o continuous integration, que debe pasar antes de un aterrizaje de confirmación en la twig remota. Otro ejemplo es cuando un proyecto es administrado por un set de committers que solo aceptan requestes de extracción (los proyectos de GitHub a menudo lo hacen). Como desarrollador, es posible que desee crear una twig de características y luego enviar esa twig para su revisión (o enviar una request de extracción a un committer de repository). Entonces, es posible que desee continuar con el desarrollo local, mientras que mis compañeros de equipo revisan de manera asincrónica mi código y las comstackciones de CI completas. Para continuar el desarrollo además de mi confirmación anterior, puedo crear una segunda twig local que rastree desde mi primera sucursal local. Esto me permite comstackr desde mi primer commit, aunque ese commit no haya llegado a la twig remota upstream. Además, si alguien sugiere cambios en la revisión del código para mi primera sucursal o falla la compilation de CI, puedo actualizar esa twig y luego volver a establecer la base de esos cambios en las sucursales locales de flujo descendente. Aquí se explica cómo configurar una twig para rastrear otra twig local.

Dada una twig local de características:

 $ git co -b branch-1 $ git branch -u origin/master Switched to a new branch 'branch-1' $ git branch -vv * branch-1 9f0c361 [origin/master] Some commit message master 85ede1a [origin/master] Some commit message 

Esto muestra que las twigs de seguimiento locales master y branch-1 rastrean la twig master en el control remoto de origin . Ahora puedo crear otra twig y configurarla para rastrear la twig de seguimiento local branch-1 .

 $ git co -b branch-2 Switched to a new branch 'branch-2' $ git branch -u branch-1 branch-2 Branch branch-2 set up to track local branch branch-1 by rebasing. $ git branch -vv branch-1 85ede1a [origin/master] Some commit message * branch-2 85ede1a [branch-1] Some commit message master 85ede1a [origin/master] Some commit message