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

Question

Escuché que en Git, puede dejar que rastreen otra local branch B.

¿Por qué alguien querría hacer eso?

Answer 1

Un ejemplo que puedo pensar es si usted tiene una sucursal 'estable'. Entonces sería bueno si pudieras crear una nueva rama, "experimentar" por ejemplo, y dejar que rastreara la rama estable.

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

Aparte de eso, podría ser por coherencia (eso es solo una conjetura).

Answer 2

Las principales cosas que me vienen a la mente para tener una sucursal local otra rama local son (1) mensajes más informados de Git con respecto a una rama delante/detrás de la rama rastreada y (2) ganchos de activación.

Un área Git muestra más información cuando se crea una sucursal. La creación de un basic branch tiene el siguiente aspecto:

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

Si bien la creación de un tracking branch se parece a:

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

Esto añadiría lo siguiente en .git/config:

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

Después de cometer algunos cambios en las ramas A y B, ejecutando git status -s -b en la rama A muestra ## A mientras que en la rama B muestra ## B...master [ahead 1, behind 1], proporcionando alguna información rápida sobre la relación entre las ramas B y master.

La otra área en la que es posible que desee una bifurcación local para rastrear otra sucursal local es activar hooks; en particular pre-receive, update, post-receive y post-update durante un git push. Es posible que tenga ganchos para, por ejemplo, desencadenar una compilación en un servidor de integración continua, realizar comprobaciones de encabezado de licencia, verificar errores de formato de espacios en blanco, etc.

Answer 3

Tenga en cuenta que la información de adelante/detrás que tiene entre una rama 'B' y otro 'A' rastreado por los primeros trabajos solo si la configuración 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 funcionará también.

Al momento de pagar una rama que se establece para construir en la parte superior de la otra rama (a menudo, una rama de seguimiento a distancia), "git checkout" informa cómo su trabajo se relaciona con la otra rama, por ejemplo,

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

Antes, cuando se introdujo esta característica, esto se realiza sólo para las ramas que se acumulan en las ramas de seguimiento a distancia, pero 5e6e2b4 (Agrega ramas locales se comportan como las sucursales remotas cuando --tracked, 2009-04-01 , git 1.6.3) se agregó soporte para dar el mismo informe para las sucursales que se basan en otras sucursales locales (es decir, sucursales cuyas variables branch.*.remote se establecen en '.').
A diferencia del soporte para las ramas que se basan en ramas de seguimiento remoto, sin embargo, este no tuvo en cuenta el hecho de que la configuración branch.*.merge tiene permitido registrar un nombre de rama acortado.

Cuando branch.*.merge se establece en 'master' (no 'refs/heads/master'), es decir, "mi sucursal se basa en la rama local de 'maestro'", esto provocó "git checkout" reportar:

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

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

Answer 4

En muchas ocasiones es útil realizar el seguimiento de 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 solicitudes de inserción. Un ejemplo es un sistema de revisión de código o integración continua, que debe pasar antes de un aterrizaje de confirmación en la rama remota. Otro ejemplo es cuando un proyecto es administrado por un conjunto de committers que solo aceptan solicitudes de extracción (los proyectos de GitHub a menudo lo hacen). Como desarrollador, es posible que desee crear una rama de características y luego enviar esa rama para su revisión (o enviar una solicitud de extracción a un committer de repos). 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 compilaciones de CI completas. Para continuar el desarrollo además de mi confirmación anterior, puedo crear una segunda rama local que rastree desde mi primera sucursal local. Esto me permite compilar desde mi primer commit, aunque ese commit no haya llegado a la rama remota upstream. Además, si alguien sugiere cambios en la revisión del código para mi primera sucursal o falla la compilación de CI, puedo actualizar esa rama y luego volver a establecer la base de esos cambios en las sucursales locales de flujo descendente. Aquí se explica cómo configurar una rama para rastrear otra rama local.

dado una rama de la característica local:

$ 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 demuestra que las ramas locales de seguimiento y masterbranch-1 tanto realizar un seguimiento de la rama master en el origin remoto. Ahora puedo crear otra rama y configurarla para rastrear la rama 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