2012-06-12 8 views
7

Sto lavorando su un progetto e ho un repository git centrale. Questo progetto è uno scheletro per essere una linea di base per un certo numero di bivi.Git Tracking Upstream

È possibile configurare il mio repository di lavoro locale per un fork per tracciare il centro del progetto come origine e tracciare il master dello scheletro come ramo separato denominato upstream che rileva il master dello scheletro per selezionare le modifiche allo scheletro?

Credo che voglio che il mio flusso di lavoro di essere qualcosa di simile:

Creare scheletro >> Forcella >> Scheletro Scheletro estrae i cambiamenti da Forcella 2 >> Forcella 1 estrae i cambiamenti da scheletro

Esiste un processo meglio fare ciò che ho descritto?

risposta

7

Leggere la pagina "Step 3: Configure remotes" della GitHub "Dalla tavola un repo" (lo so che non ha citato GitHub, ma è ancora attuale)

  • origin è l'indirizzo remoto della forcella, che il clone locale può tirare da/il tasto
  • upstream è l'indirizzo remoto del vostro repo originale Skeleton (è possibile aggiungere con un git remote add upstream https://..../Skeleton.git)

Quindi a monte non è un ramo.

Ma si può definire una filiale locale che avrà per ramo a monte il maestro ramo di monitoraggio remoto da pronti contro termine a monte, con git branch:

git branch --set-upstream upstream_master upstream/master 

Tuttavia, non hanno bisogno di una filiale locale, soprattutto se si non potrà mai effettuare nuovi commit su di esso: è possibile confrontare il proprio master con upstream/master direttamente, dopo un git fetch upstream, selezionando a scelta ciò che è necessario da upstream/master.

+0

Questo è in linea con quello che stavo cercando di fare che ha portato a questa domanda. Il comando 'git branch --set-upstream upstream_master upstream/master' non funzionerà direttamente dopo' git remote add upstream/srv/repos/git/skeleton.git'. Perché? Ho accidentalmente risolto il problema cercando di risolvere il problema. Non volevo esattamente eseguire git fetch upstream nella mia struttura di lavoro principale, ma usarlo per risolvere i problemi mi consente quindi di aggiungere un ramo di monitoraggio remoto a monte/master.Suppongo che sia perché il ramo remoto upstream/master non è nel mio repo fino ad allora. –

+0

direttamente dopo 'addizione remota'? È necessario prima un 'git fetch upstream', in modo che il ramo di monitoraggio remoto' upstream/master' venga prelevato e inserito nel repository locale. Un 'git fetch' non modifica alcun file locale. – VonC

1

Secondo la descrizione, si dovrebbe rebase le forche sullo scheletro ogni volta che cambia, utilizzando

$ git rebase upstream 

Questo trasformerà la situazione come segue

initially: 
1 - 2 - 3 <- upstream 
     \- 4 <- fork 

upstream changes: 
1 - 2 - 3 - 5 - 6 <- upstream 
     \- 4 <- fork 

after rebase: 
1 - 2 - 3 - 5 - 6 <- upstream 
       \- 4 <- fork 

In altre parole, la forcella si sembra come se fosse biforcato dalla versione più recente dello skeletton.

Lo svantaggio di questo approccio è che cambia la cronologia delle forcelle ... Se non si desidera questo, è sufficiente unire a monte il fork (non c'è bisogno di cherry-pick, credo).

+0

Se i file sono stati rimossi in upstream dopo il fork e prima del rebase, cosa succederà quando git applica modifiche a quei file? –

+0

Se non hai modificato i file, verranno rimossi durante il rebase. Se li hai modificati, avrai un conflitto che dovrai risolvere manualmente. – Sjlver