Lavorare con Git su più macchine

Gestisco quotidianamente entrambe le soluzioni proposte. Ci sono due concetti chiave per gestirli bene.

1. Utilizza i rami degli argomenti. Credo che la cronologia della produzione dovrebbe essere incontaminata. Di conseguenza, dedico molto tempo a rendere la mia storia del ramo production logica, replicabile e debuggabile. Tuttavia, quando si utilizzano più macchine, è necessario eseguire occasionalmente dei lavori in corso. Usa un ramo argomento. Puoi pull e push questo ramo da entrambe le macchine con poco sforzo e quando è pronto per unire in master o production rebase per creare una cronologia più gestibile.
2. L'utilizzo di un repository condiviso su una rete va bene, a meno che non lo stia condividendo anche con altri utenti. Utilizziamo un repository condiviso per gli script, con il nome creativamente il repository scripts . All'inizio sembrava una buona idea dato che il repository non cambia spesso, ma nel tempo è diventato un vero incubo. È facile sovrascrivere il lavoro degli altri e finisci per spendere tanto tempo nel traffico aereo controllando chi sta distribuendo il repository mentre ci lavori.

La soluzione migliore è mantenere un repository locale su ogni macchina e condividere i rami degli argomenti tra di loro tramite un telecomando. Impegnati a lavorare su quei rami tutte le volte che vuoi. Finché sei disposto a rebase di loro in una cronologia più comprensibile, in pratica è abbastanza efficace.

Se ti trovi a lavorare su più di un ramo argomento durante il giorno ma non vuoi spingerlo individualmente al remoto, git push <remote> imposterà per impostazione predefinita tutti i rami corrispondenti a <remote> . Questo predefinito cambierà in una versione successiva di git , ma può essere annullato da impostando push.default in un file di configurazione o specificando il corrispondente refspec :

git push <remote> :

Sono arrivato a questo da una direzione leggermente diversa (e uso mercuriale, ma filosoficamente è lo stesso). Questa non è la mia idea, la uso e funziona solo per i miei effetti personali.

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

Quando cambio le caselle è solo 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 altrettanto bene per di più - e per fornire un backup extra. Tutto ciò che è "fatto" viene spinto a Kiln (se io stavo usando git e capisco correttamente il modo in cui il gioco è giocato, allora sarebbe il punto in cui faccio un rebase).

Quello che davvero non vorrei fare è scappare da una cartella condivisa ... se stai usando un DVCS allora puoi anche goderti il vantaggio.

Se non tutte le macchine sono sempre attive, non c'è un proiettile d'argento: prima di spegnere la macchina, devi spostare le modifiche da qualche altra parte. Spingo su un server privato, ma potrebbe anche essere un 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. Io uso uno script push.sh per quello, che eseguo ogni volta che ho finito di lavorare su una macchina.

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 modo gestibile.

Potresti fare la tua seconda alternativa, ma il problema è che c'è una sola directory di lavoro di repository. Quindi l'albero di lavoro può essere in uno solo stato alla volta - non c'è Joe che lavora su un ramo e Jane lavora su un altro. Quindi gli sviluppatori possono sovrascrivere i cambiamenti l'uno dell'altro, manipolare il lavoro degli altri. Perché, è come non avere affatto il controllo della versione!

C'è una via di mezzo chiamata, con un repository spoglio su un'unità di rete, e con i 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", è "pubblica". Il lavoro che vuoi che i tuoi colleghi vedano e utilizzino.