Perché git ti permette di "cambiare la storia"? [duplicare]

Question

Perché git ti permette di "cambiare la storia"? [duplicare]

#1 da (17 voti)
#2 da (9 voti)
#3 da (2 voti)

22

Ho esperienza nell'uso di svn e recentemente ho iniziato a imparare git. Sono rimasto piuttosto scioccato nell'apprendere che git ha funzionalità che ti consentono di "riscrivere la cronologia".

Venendo da svn, avevo accettato come sacrosanto il principio del controllo del codice che una volta che un cambiamento è stato eseguito, non c'è modo di "annullare" il commit stesso ... il massimo che si può fare è eseguire un commit successivo che effettivamente " inverte "le modifiche apportate al commit precedente, ma si può sempre riprodurre lo stato di qualsiasi commit eseguito in passato.

Qual è la logica per cambiare questo "principio"? C'è qualcosa di diverso in git che lo rende OK, o la progettazione di git riflette una "filosofia" diversa del controllo del codice sorgente che differisce dalla "filosofia" di svn?

git version-control svn

posta JoelFan 16.01.2013 - 16:51

fonte

3 risposte

Leggi altre domande sui tag git version-control svn

Il modo migliore per fare riferimento ai dati del database statico nel codice? Ridurre il consumo di memoria [chiuso]

score 17 · Answer 1

La ragione più importante è la sicurezza. Supponiamo di aver accidentalmente archiviato un file che contiene una password in chiaro o altre informazioni sensibili. Anche se controlli una nuova versione con le informazioni cancellate, è ancora visibile nella cronologia.

Può anche essere utile a volte rendere la storia "più pulita". Ad esempio, quando lavori nel tuo repository, puoi verificare in più piccole modifiche mentre provi a vedere cosa funziona. Quando finalmente il cambiamento funziona, potresti non voler spingere tutte quelle modifiche su un altro repository, in modo da poterle trasformare in una singola modifica. Mentre stai sviluppando nella tua sandbox privata, probabilmente vorresti una cronologia molto dettagliata di quali modifiche hai apportato e la possibilità di tornare alle versioni precedenti. Una volta che hai finalmente risolto il problema e la correzione si rivela, ad esempio, un cambiamento di una sola riga che si spiega da sé, non c'è bisogno di spingere tutta quella cronologia su un altro repository (forse uno che funge da repo centrale per il progetto).

score 9 · Answer 2

Git segue il principio di non cementare la politica nel codice, che la flessibilità nelle mani di utenti altamente tecnici è più importante che limitarsi a fare errori. La cronologia di riscrittura è impossibile da eseguire in git senza che le persone se ne accorgano, poiché l'hash SHA-1 per un commit e tutti i successivi commit cambieranno. Questo è in realtà un miglioramento da svn, che non rende facile riscrivere la cronologia, ma rende possibile, e rende difficile da rilevare quando lo fai.

score 2 · Answer 3

CVCS e DVCS hanno una grande differenza non solo nella prima lettera delle abbreviazioni, ma nei principi fondamentali: per il commit pubblicato CVCS è cronologia condivisa comune , commit ma non spinto commit in DVCS - cronologia personale locale , che non interessa nessuno tranne l'autore.

In quest'ultimo caso le mutazioni della storia sono solo problemi dell'unica persona, responsabile del proprio pasticcio e del modo caotico di lavorare.

E, infine, è solo un altro stile , stile anche con i diritti della vita. "La pratica è il criterio della verità", quindi: se la riscrittura non viene buttata via, nulla impedisce di usarla nello strumento, lì può essere fatta facilmente.