Lavorare con Git su più macchine

Questo può sembrare un po 'strano, ma mi chiedo un buon modo di lavorare in Git da più macchine collegate in qualche modo. Mi sembra di avere due opzioni e di vedere vantaggi su entrambi i lati:

• Usa git stesso per la condivisione, ogni macchina ha il suo repository e devi recuperarli.
  • Puoi lavorare su entrambe le macchine anche se l'altra è offline. Questo di per sé è piuttosto grande, penso.
• Utilizzare un repository condiviso sulla rete tra computer.
  • Non è necessario eseguire git pull ogni volta che si cambia macchina, poiché il codice è sempre aggiornato.
  • Non preoccuparti di aver dimenticato di inviare il codice dall'altra tua macchina non di hosting, che ora è fuori portata, dal momento che stavi lavorando su una condivisione file su questa macchina.

La mia intuizione dice che tutti generalmente scelgono la prima opzione. Ma il rovescio della medaglia che vedo è che potresti non essere sempre in grado di accedere al codice dalle altre tue macchine, e certamente non voglio spingere tutti i miei rami WIP su github alla fine di ogni giorno. Inoltre, non voglio lasciare sempre i miei computer accesi in modo da poterli recuperare direttamente da loro. Infine, un aspetto secondario è che tutti i comandi git per mantenere aggiornati più rami possono diventare noiosi.

C'è un terzo punto di vista su questa situazione? Forse sono disponibili alcuni strumenti di terze parti che aiutano a semplificare questo processo? Se affrontate questa situazione regolarmente, cosa suggerite?

Mi occupo quotidianamente di entrambe le soluzioni proposte. Esistono due concetti chiave per gestirli bene.

1. Usa i rami dell'argomento. Credo che la storia della produzione dovrebbe essere incontaminata. Di conseguenza passo molto tempo a rendere productionla cronologia del mio ramo logica, replicabile e debuggabile. Quando si utilizzano più macchine, tuttavia, è necessario occasionalmente eseguire il commit dei lavori in corso. Usa un ramo argomento. Puoi pulle pushquesto ramo da entrambe le macchine con poco sforzo, e quando è pronto a fondersi mastero production rifondarlo per creare una storia più sostenibile.
2. L'uso di un repository condiviso su una rete va bene, a meno che non lo si condivida anche con altri utenti. Usiamo un repository condiviso per gli script, chiamato in modo creativo il scriptsrepository. All'inizio sembrava una buona idea in quanto il repository non cambia spesso, ma nel tempo è diventato un vero incubo. È facile sovrascrivere a vicenda il lavoro e si finisce per dedicare tutto il tempo al traffico aereo che controlla chi sta distribuendo il repository mentre lo si lavora.

La soluzione migliore è mantenere un repository locale su ogni macchina e condividere gli argomenti tra loro tramite un telecomando. Impegna i lavori in corso in tali filiali tutte le volte che vuoi. Finché sei disposto a rebasefarli entrare in una storia più comprensibile, nella pratica è abbastanza efficace.

Se ti trovi a lavorare su più di un argomento durante il giorno ma non vuoi spingerli singolarmente sul telecomando, git push <remote>per impostazione predefinita spingerai tutti i rami corrispondenti in <remote>. Questa impostazione predefinita cambierà in una versione successiva di git , ma può essere sostituita impostando push.defaultun file di configurazione o specificando la corrispondenza refspec:

git push <remote> :

Se non tutte le macchine sono sempre accese, non c'è proiettile d'argento: prima di spegnere la macchina, devi spingere le modifiche da qualche altra parte. Spingo su un server privato, ma potrebbe anche essere dropbox o una chiave USB che porti ovunque.

Sì, spingere più rami in un posto centrale può diventare noioso, ma non dovrebbe essere troppo difficile da scrivere. Per questo uso uno push.shscript, che eseguo ogni volta che ho finito di lavorare su una macchina.

Sono arrivato da una direzione leggermente diversa (e uso mercuriale, ma filosoficamente è lo stesso). Questa non è una mia idea, la uso solo e funziona per le mie cose personali.

Ho creato un clone dei miei repository in una cartella SkyDrive (potrebbe anche essere un dropbox o un altro strumento di sincronizzazione magica di tua scelta), quindi ho configurato le istanze sui miei due computer per inviare automaticamente al repository SkyDrive su commit.

Quando cambio scatole è solo una questione di fare un pull e un aggiornamento - in teoria lavorerai sempre in modo lineare anche se è in più repository.

La chiave qui è che il repository SkyDrive esiste principalmente per fornire un mezzo per garantire che io abbia accesso a più o meno l'ultima versione del codice su entrambe le mie macchine - anche se funzionerebbe anche per più - e per fornire un backup extra. Tutto ciò che viene "fatto" viene spinto a Kiln (se stavo usando git e capissi correttamente il modo in cui si gioca, sarebbe il punto in cui faccio un rebase).

Quello che non vorrei davvero fare è scappare da una cartella condivisa ... se stai usando un DVCS, potresti anche goderne il vantaggio.

La prima delle tue due alternative è la risposta. Ciò è implicito dalla "D" in "DVCS". Ogni utente ha la propria istanza locale del repository e i repository parlano tra loro in modi gestibili.

Potresti fare la tua seconda alternativa, ma il problema è che esiste solo una directory di lavoro del repository. Quindi l'albero di lavoro può trovarsi in un solo stato alla volta: non c'è Joe che lavora su un ramo e Jane che lavora su un altro. In questo modo gli sviluppatori possono sovrascrivere le modifiche reciproche, manipolarsi a vicenda. Perché, è come non avere affatto il controllo della versione!

C'è una via di mezzo chiamata, con un repository nudo su un'unità di rete e con singoli utenti che effettuano il check-in e il check-out. Questo separa il tuo lavoro WIP (che sì, mantieni localmente) dal lavoro che pubblichi nel repository. Non è "salva", ma "pubblica". Il lavoro che vuoi che i tuoi colleghi vedano e utilizzino.