In Git, le filiali locali possono rintracciarsi l'un l'altro - come è utile?

Question

Ho sentito che in Git, è possibile lasciare un traccia un altro local branch B.

Perché qualcuno dovrebbe volerlo fare?

Answer 1

Un esempio che posso pensare è se si dispone di un ramo "stabile". Quindi sarebbe bello se potessi creare un nuovo ramo, "esperimento" per esempio, e lasciare tracciare il ramo stabile.

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

Diverso da quello che potrebbe essere per consistenza (è solo una supposizione).

Answer 2

Le cose principali che vengono in mente per avere un ramo locale tracciare un altro ramo locale sono (1) messaggi più informati da Git riguardo a un ramo avanti/dietro del ramo tracciato e (2) innesco di innesco.

Un'area Git visualizza ulteriori informazioni quando si crea un ramo. Creazione di un basic branch è simile al seguente:

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

Durante la creazione di tracking branch assomiglia:

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

Questo sarebbe aggiungere quanto segue in .git/config:

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

Dopo aver commesso alcuni cambiamenti sui rami A e B, esecuzione git status -s -b sul ramo A visualizza ## A mentre sul ramo B visualizza ## B...master [ahead 1, behind 1], fornendo alcune informazioni rapide sul rapporto tra i rami B e master.

L'altra area in cui è possibile che un ramo locale tenga traccia di un altro ramo locale deve attivare hooks; in particolare pre-receive, update, post-receive e post-update durante un git push. Ad esempio, è possibile attivare una build su un server di integrazione continua, eseguire alcuni controlli di intestazione di licenza, verificare errori di formato spazi bianchi, ecc.

Answer 3

Si noti che le informazioni avanti/indietro che si hanno tra un ramo 'B' e un altro 'A' tracciati dal primo funziona solo se la configurazione del ramo.B.merge è strettamente definita: refs/heads/master.
Non funzionerebbe se si definisce liberamente "master".

Ma con commit 05e7368, fatto da Junio C Hamano (gitster) per Git 2.3.0 (Q1 2015), funzionerà anche questo.

Al check-out un ramo che è impostato per costruire su un altro ramo (spesso, una filiale remota-tracking), "git checkout", riferisce come il vostro lavoro si riferisce al ramo, per esempio

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

Ai tempi in cui questa funzione è stata introdotta, questo è stato fatto solo per i rami che si basano sulle filiali remote-tracking, ma 5e6e2b4 (Fai sezioni locali si comportano come filiali remote quando --tracked, 2009-04-01 , git 1.6.3) ha aggiunto il supporto per fornire lo stesso report per i rami che si basano su altre filiali locali (ovvero i rami le cui variabili branch.*.remote sono impostate su ".").
Diversamente dal supporto per la creazione di filiali su filiali di localizzazione remota, tuttavia, questo non ha tenuto conto del fatto che la configurazione branch.*.merge è autorizzata a registrare un nome di diramazione abbreviato.

Quando branch.*.merge è impostato su 'master' (non 'refs/heads/master'), vale a dire "il mio ramo si basa sul ramo locale 'padrone'", questo ha causato "git checkout" a riferire:

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

L'upstream è il nostro repository e sicuramente non è andato, quindi questo output non ha senso.

Answer 4

Ci sono molte occasioni in cui è utile rintracciare un altro ramo locale. Ad esempio, in alcuni workflow di git, c'è qualcosa in atto che protegge il master dalla ricezione diretta delle richieste push. Un esempio è una revisione del codice o un sistema di integrazione continua, che deve passare prima di un atterraggio di commit sul ramo remoto. Un altro esempio è quando un progetto è gestito da un gruppo di committer che accetta solo richieste pull (i progetti GitHub spesso lo fanno). Come sviluppatore, potrei voler creare un branch di funzionalità e quindi inviare quel ramo per la revisione (o inviare una richiesta di pull a un committente di repository). Quindi, potrei voler continuare lo sviluppo locale mentre i miei compagni di squadra riesaminano in modo asincrono il mio codice e completano le build CI. Per continuare lo sviluppo sopra il mio commit precedente, posso creare un secondo ramo locale che tiene traccia dal mio primo ramo locale. Questo mi permette di costruire dal mio primo commit, anche se il commit non è arrivato al ramo remoto upstream. Inoltre, se qualcuno suggerisce modifiche al riesame del codice per il mio primo ramo o se il build dell'elemento della configurazione non riesce, è possibile aggiornare quel ramo e quindi rebase tali modifiche in rami locali a valle. Ecco come impostare un ramo per tracciare un altro ramo locale.

Dato un ramo di caratteristica locale:

$ 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 

Questo dimostra che monitoraggio locali rami master e branch-1 sia traccia ramo master sul origin remoto. Ora posso creare un altro ramo e configurarlo per tracciare il ramo di localizzazione locale 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