Hai ragione che una volta che un repository locale viene trasferito in una posizione remota, entrambe le posizioni contengono le revisioni successive. Inoltre, se qualcuno cancella erroneamente alcuni file e trasferisce questa modifica nel repository remoto, puoi comunque recuperarli facilmente dalla cronologia.
Qual è il rischio di perdere entrambe le copie? Dipende dall'infrastruttura in uso. Considera quegli scenari:
-
Se utilizzi GitHub, ad esempio, il rischio è estremamente basso.
-
D'altra parte, se la posizione remota è il tuo server aziendale, allora forse non è veramente remoto.
Che succede se si trova nello stesso edificio in cui lavori? Cosa succede se un incendio distrugge sia il server che il computer?
Se il server è realmente geograficamente remoto, potrebbe essere che un virus si propaga sia sul server aziendale che sulla macchina?
Scopri come la posizione remota gestisce il repository. Se si tratta di un server aziendale, contatta il tecnico IT che sa come vengono gestiti i backup (se non conosce la risposta, questo è un brutto segno).
- Quanto spesso fanno i backup?
- Dispongono di backup off-site?
- Hanno mai testato i loro backup o sono in attesa di un disastro per scoprire che l'ultimo backup funzionante è stato effettuato tre anni fa?
Anche con soluzioni come GitHub, in una brutta giornata, si rischia di perdere la connessione a Internet e allo stesso tempo avvitare i file del repository. Se l'attesa di una connessione Internet per tornare non è un'opzione, allora un backup locale è un'opzione valida.
Tutto si riduce al costo del backup rispetto al rischio di perdere tutto. Probabilmente stai già facendo un backup regolare della tua macchina, facendo il backup di tutto. Includere il tuo codice sorgente ha senso, anche se hai valutato il rischio di un disastro per essere infinitamente piccolo.