2012-09-20 12 views
5

Alcuni Background:git singolo sviluppatore w/più macchine - rebase e si impegna mostrando due volte

  1. Io sono un singolo sviluppatore che lavora su un sito.
  2. Sto usando git per il controllo della versione.
  3. I dispone di più computer che io lavoro da: ufficio, casa, computer portatile e

Attualmente, ho un centrale, repository nudo sul mio server. Ogni computer clona e invia modifiche a questo repository. Attualmente ho un master di ramo e un dev di ramo. Tutto il lavoro è fatto nel ramo dev. Il master è sempre il codice di produzione attuale e stabile. Le modifiche possono essere applicate al Master in qualsiasi momento insieme alle modifiche in corso in dev.

mio flusso di lavoro di tutti i giorni è composto da:

git checkout dev 
//pull in changes from remote 
git pull 
//make and commit changes as need throughout the day 
git add -u 
git commit 
//these steps only happens when I know master has changed 
git checkout master 
git pull 
git checkout dev 
git rebase master //to get changes to master into dev branch 
//push changes to central remote at end of day 
git push 

credo che questo dovrebbe essere un flusso di lavoro abbastanza standard per un singolo sviluppatore.

Ora con tutto ciò che è fuori strada, allo scopo della mia domanda. Recentemente mi sono imbattuto in una situazione che non sono sicuro di come gestire correttamente e come prevenirlo in futuro. Attualmente, il mio ramo dev è un ramo di sviluppo di lunga durata che è una grande riscrittura di una parte del sito. Come tale, è in sviluppo da un paio di mesi. Mentre ho svolto questo lavoro, ho anche apportato piccole modifiche/correzioni di errori al Master. Quando finisco una delle modifiche a Master, rebase dev su Master per ottenere i cambiamenti, quindi li spingo al repository centrale. Questo ha funzionato bene.

Tuttavia, ho apportato una modifica al Master un paio di giorni fa: il primo di tali cambiamenti in circa un mese. Quando sono andato a rebase, sembrava che si scatenasse l'inferno. Stavo ottenendo conflitti di merge su file che non esistevano in Master, e ricevevo sempre gli stessi conflitti negli stessi file. Dopo aver trascorso la maggior parte della giornata cercando di risolvere tutti i conflitti, alla fine ho rinunciato.

Questa mattina, sono andato a riprovare, ma prima di iniziare ho esaminato la storia del commit del progetto e ho trovato qualcosa di piuttosto strano. Ho scoperto che circa 15 dei commit sono stati ripetuti. Ha mostrato tutti i commit dal 07/12/2012 al 24/08/2012. Quindi, ho elencato di nuovo gli stessi commit, tutti con hash SHA diversi. Non me ne accorsi finché non vidi che le date dei commit erano elencate tutte in ordine cronologico come ci si aspetterebbe, ma poi improvvisamente tornò di nuovo nel passato.

Per risolvere ho eseguito un altro rebase, ma ho saltato il commit duplicato. Quando l'ho fatto, tutto ha funzionato esattamente come mi sarei aspettato senza alcun conflitto.

Quindi, la mia domanda per voi ragazzi è come sono stati fatti questi commit due volte, e come posso evitare che questo incubo possa ripetersi in futuro? Come suggerisce il titolo della domanda, presumo che il problema abbia a che fare con il mio uso di rebaseing e push del ramo rebased. Ma sto solo indovinando. Ho solo bisogno di aiuto per capire cosa ho fatto di sbagliato.

risposta

1

Ritengo che il modello sia essenzialmente lo stesso di tre sviluppatori, dal momento che sono presenti tre macchine di sviluppo. Quindi, il tuo ramo dev è condiviso in questo senso. Ho anche letto su SO che la ridefinizione come ramo condiviso porta a problemi, ed è meglio unire che rebase rami condivisi. Dopo aver letto che ho iniziato a utilizzare rebase solo per le filiali private, con buoni risultati. Suggerirei di creare un repository di test e provare i due approcci per vedere come si confrontano.

Se riesco a trovare l'altra domanda SO, aggiungerò un collegamento qui.

Edit:

Qui è Rebasing remote branches in Git

Naturalmente, ci sono molte opinioni diverse su questo. :)

+0

Grazie per il collegamento. Se sto capendo te e il link, correttamente, dal momento che lavoro nello stesso ramo su tutte le macchine, dovrei unire le modifiche da Master invece di rebasing? Dovrei essere preoccupato di unirmi ai cambiamenti dal Master su base regolare? O dovrei salvarlo fino a quando non sarò pronto a unire il ramo dev in master? – adear11

+0

Prego. –

+0

Ecco come ho capito anche questo collegamento. Non è l'unico approccio, ma è quello che sembra funzionare bene. Dove sto usando questo approccio, mi unisco abbastanza regolarmente. Lo preferisco, dal momento che le risoluzioni dei conflitti sono più facili quando si tratta di una serie di piccoli conflitti piuttosto che di una grande risoluzione di conflitto, che di solito è vicina a una scadenza incombente. –