Come assicurarsi che il mio codice repository git sia sicuro?

Question

Se la nostra organizzazione dovesse passare da un VCS del server centrale come sovversione a un VCS distribuito come git, come posso assicurarmi che tutto il mio codice sia al sicuro da guasti hardware?

Con un VCS del server centrale ho solo bisogno di eseguire il backup del repository ogni giorno. Se stessimo usando un DVCS ci sarebbero un sacco di rami di codice su tutti i computer degli sviluppatori, e se quell'hardware dovesse fallire (o uno sviluppatore dovesse perdere il suo laptop o farlo rubare) allora non avremmo alcun backup .

Nota che non considero una buona opzione " fare in modo che gli sviluppatori spingano i rami su un server " - questo è noioso e il gli sviluppatori finiranno per non farlo.

C'è un modo comune per aggirare questo problema?

Alcuni chiarimenti:

Con un VCS con server centrale nativo, allora tutto deve essere sul server centrale tranne le modifiche più recenti dello sviluppatore. Pertanto, ad esempio, se uno sviluppatore decide di eseguire il branch per eseguire un bugfix, tale branch si trova sul server centrale e è immediatamente disponibile per il backup.

Se stiamo usando un DVCS, lo sviluppatore può fare una filiale locale (e in effetti molte filiali locali). Nessuno di quei rami si trova sul server centrale e è disponibile per il backup fino a quando lo sviluppatore non pensa, "oh sì, dovrei inviarlo al server centrale".

Quindi la differenza che sto vedendo (correggimi se sbaglio!): Funzionalità e correzioni di bug parzialmente implementate probabilmente non saranno disponibili per il backup sul server centrale se stiamo usando un DVCS, ma sono normali VCS. Come posso mantenere quel codice sicuro?

Answer 1

Penso che scoprirai che in pratica gli sviluppatori preferiranno utilizzare un repository centrale piuttosto che spingere e tirare tra i repository locali l'uno dell'altro. Dopo aver clonato un repository centrale, mentre lavori su tutti i rami di tracciamento, il recupero e il push sono comandi banali. Aggiungere mezza dozzina di telecomandi a tutti i repository locali dei tuoi colleghi è una seccatura e questi repository potrebbero non essere sempre accessibili (spento, su un laptop portato a casa, ecc.).

Ad un certo punto, se state tutti lavorando allo stesso progetto, tutto il lavoro deve essere integrato. Ciò significa che è necessario un ramo di integrazione in cui tutte le modifiche si incontrano. Questo naturalmente deve essere accessibile in qualche luogo da tutti gli sviluppatori, non appartiene, ad esempio, al laptop dello sviluppatore principale.

Dopo aver impostato un repository centrale, è possibile utilizzare un flusso di lavoro in stile cvs / svn per effettuare il check-in e l'aggiornamento. cvs update diventa git fetch e rebase se si hanno modifiche locali o semplicemente git pull in caso contrario. cvs commit diventa git commit e git push.

Con questa configurazione ti trovi in ??una posizione simile con il tuo sistema VCS completamente centralizzato. Una volta che gli sviluppatori hanno inviato le loro modifiche (git push), che devono fare per essere visibili al resto del team, si trovano sul server centrale e verrà eseguito il backup.

Ciò che prende disciplina in entrambi i casi è impedire agli sviluppatori di mantenere le modifiche a lungo termine fuori dal repository centrale. La maggior parte di noi ha probabilmente lavorato in una situazione in cui uno sviluppatore sta lavorando alla funzione 'x' che necessita di un cambiamento fondamentale in alcuni codici core. La modifica farà sì che tutti gli altri debbano ricostruire completamente, ma la funzione non è ancora pronta per lo stream principale, quindi continua a controllarla fino a quando non sarà il momento opportuno.

La situazione è molto simile in entrambe le situazioni, anche se ci sono alcune differenze pratiche. Usando git, poiché puoi eseguire commit locali e gestire la cronologia locale, la necessità di spingere nel repository centrale potrebbe non essere avvertita tanto dal singolo sviluppatore quanto con qualcosa come cvs.

D'altra parte, l'uso di commit locali può essere usato come un vantaggio. Spingere tutti i commit locali in un posto sicuro nel repository centrale non dovrebbe essere molto difficile. Le filiali locali possono essere archiviate in uno spazio dei nomi di tag specifico dello sviluppatore.

Ad esempio, per Joe Bloggs, un alias potrebbe essere creato nel suo repository locale per eseguire qualcosa di simile al seguente in risposta a (ad esempio) git mybackup .

git push origin +refs/heads/*:refs/jbloggs/*

Questo è un singolo comando che può essere utilizzato in qualsiasi momento (come la fine della giornata) per assicurarsi che venga eseguito il backup sicuro di tutte le sue modifiche locali.

Questo aiuta con tutti i tipi di disastri. La macchina di Joe esplode e può usare un'altra macchina e recuperare viene salvato, e continua da dove si era interrotto. Joe è malato? Fred può recuperare i rami di Joe per afferrare quella "necessaria" correzione che ha fatto ieri ma non ha avuto la possibilità di testare contro il maestro.

Per tornare alla domanda originale. Deve esserci una differenza tra dVCS e VCS centralizzato? Dici che le funzionalità e le correzioni dei bug implementate a metà non finiranno nel repository centrale nel caso dVCS, ma direi che non dovrebbe esserci alcuna differenza.

Ho visto molti casi in cui una funzionalità parzialmente implementata rimane su una casella di lavoro degli sviluppatori quando si utilizza VCS centralizzato. Prende una politica che consente di archiviare le funzioni scritte a metà nello stream principale o di prendere una decisione per creare una filiale centrale.

Nel dVCS può succedere la stessa cosa, ma la stessa decisione dovrebbe essere presa. Se esiste un lavoro importante ma incompleto, deve essere salvato a livello centrale. Il vantaggio di git è che la creazione di questo ramo centrale è quasi banale.

Answer 2

Penso che sia un errore che usare un VCS distribuito significhi necessariamente che devi usarlo in modo completamente distribuito. È completamente valido impostare un repository git comune e dire a tutti che il repository è quello ufficiale. Per il normale flusso di lavoro di sviluppo, gli sviluppatori dovrebbero estrarre le modifiche dal repository comune e aggiornare i propri repository. Solo nel caso in cui due sviluppatori collaborino attivamente su una specifica funzionalità potrebbero aver bisogno di estrarre le modifiche direttamente l'una dall'altra.

Con più di alcuni sviluppatori che lavorano su un progetto, sarebbe seriamente noioso dover ricordare di attirare i cambiamenti da tutti gli altri. Cosa faresti se non non avessi un repository centrale?

Al lavoro abbiamo una soluzione di backup che esegue quotidianamente il backup delle directory di lavoro di tutti e scrive l'intero lotto su un DVD ogni settimana. Pertanto, sebbene disponiamo di un repository centrale, viene eseguito il backup anche di ogni singolo.

Answer 3

Non è raro usare un "centrale" server come autorità in DVCS, che fornisce anche il posto per eseguire i backup.

Answer 4

Trovo che questa domanda sia un po 'bizzarra. Supponendo che tu stia utilizzando un sistema di controllo della versione non distribuito, come CVS, avrai un repository sul server centrale e lavori in corso sui server degli sviluppatori. Come si esegue il backup del repository? Come si esegue il backup del lavoro in corso degli sviluppatori? La risposta a queste domande è esattamente ciò che devi fare per gestire la tua domanda.

Utilizzando il controllo della versione distribuita, i repository sui server degli sviluppatori sono solo lavori in corso. Vuoi eseguire il backup? Quindi esegui il backup! È così semplice.

Abbiamo un sistema di backup automatizzato che rimuove qualsiasi directory dalle nostre macchine che specifichiamo, quindi aggiungo tutti i repository e le copie funzionanti sul mio computer a quest'ultima, compresi i repository git e CVS.

A proposito, se stai usando il controllo della versione distribuita in un'azienda che rilascia un prodotto, allora avrai un repository centrale. È quello da cui rilasci. Potrebbe non essere su un server speciale; potrebbe essere sul disco rigido di alcuni sviluppatori. Ma il repository da cui si rilascia è il repository centrale. (Suppongo che se non lo avessi ancora rilasciato, potresti non averne ancora uno.) Sento che tutti i progetti hanno uno o più repository centrali. (E davvero se ne hanno più di uno, sono due progetti e uno è un fork.) Questo vale anche per l'open source.

Anche se non si disponeva di un repository centrale, la soluzione è la stessa: eseguire il backup dei lavori sui computer degli sviluppatori. Avresti dovuto farlo comunque. Il fatto che i lavori in corso si trovino in repository distribuiti anziché in copie di lavoro CVS o directory diritte non valutate è irrilevante.

Answer 5

È possibile che le home directory degli sviluppatori montino i dispositivi remoti sulla rete locale. Quindi devi solo preoccuparti di rendere sicuro l'archiviazione di rete. O forse potresti usare qualcosa come DropBox per copiare il tuo repository locale altrove senza problemi.

Answer 6

Tutti gli sviluppatori del tuo team possono avere anche le proprie filiali sul server (può essere per ticket o solo per sviluppatore, ecc.). In questo modo non interrompono la creazione nel ramo master ma riescono comunque a inviare i loro lavori in corso al server di cui viene eseguito il backup.

Il mio strumento git_remote_branch può tornare utile per quel tipo di flusso di lavoro (tieni presente che richiede Ruby). Aiuta a manipolare i rami remoti.

Come nota a margine, parlando della sicurezza dei repository, sul tuo server puoi impostare un hook post-commit che esegue un semplice clone git o git push su un altro computer ... Ottieni un backup aggiornato dopo ogni commit !

Answer 7

Usiamo rsync per eseguire il backup delle directory .git dei singoli sviluppatori in una directory sul server. Questo è impostato usando script wrapper attorno a git clone e agli hook post-commit ecc.

Poiché viene eseguito negli hook post- *, gli sviluppatori non devono ricordarsi di farlo manualmente. E poiché usiamo rsync con un timeout, se il server si arresta o l'utente lavora in remoto, possono ancora funzionare.