2011-09-07 7 views
6

Mi chiedo se c'è un limite superiore al numero di commit che un repository git può gestire.Esiste un limite superiore al numero di commit che un repository git può gestire?

In un progetto solista su cui sto lavorando in questo momento, sono stato codificato localmente, ho commesso/spinto i cambiamenti in git, poi ho tirato le modifiche sul mio server di sviluppo.

I trattare questo come un'alternativa più facile da lavorare a livello locale e cambiamenti caricamento via FTP ... Per fortuna/purtroppo è un flusso di lavoro così facile che a volte passare attraverso molti modificare/commit/push/pull/cicli di browser di aggiornamento durante la codifica.

Mi chiedo se questo sta per girare intorno e mordermi da qualche parte lungo la linea. Se è probabile che si tratti di un problema, mi chiedo come posso evitare questo problema ... Sembra che un rebase potrebbe essere la strada da percorrere, soprattutto perché non dovrò preoccuparmi di rami in conflitto ecc.

+6

git ridimensiona l'intero kernel linux (è ciò per cui è stato realizzato). Quindi, a meno che tu non abbia centinaia di MB di codice con un decennio di commit, non preoccuparti. –

risposta

11

Bene il "limite superiore" sarebbe probabilmente il punto in cui si verifica una collisione SHA1, ma poiché gli SHA sono 40 cifre esadecimali lunghe (16^40 ~ 1.4x10^48 possibilità), è così vicino a zero possibilità che non è nemmeno divertente Quindi c'è all'incirca una probabilità pari allo zero percento di avere problemi per almeno i prossimi millenni.

Esempio iperbolico (solo per divertimento): 1 commit/minuto (cambiando solo un file -> tre nuovi SHA utilizzati (file, commit, albero) = 3 nuovi sha utilizzati/minuto = ... = 1,6 milioni di sha utilizzati/anno = 1,6 miliardi scià/millenni = 1x10^-37% usato ogni millenni ... (a 1000 file/commmit/min, è ancora 3.6x10^-35%)

detto questo, se si vuoi ripulire la tua cronologia, schiacciandoli con rebase è probabilmente la soluzione migliore. Assicurati di capire le implicazioni se hai condiviso pubblicamente il repository.

Puoi anche raccogliere i rifiuti dopo la ridiscrizione liberare un po 'di spazio (assicurati che il rebase abbia funzionato correttamente, però, e potresti doverlo dire per raccogliere tutto o, per impostazione predefinita, non raccogliere nulla di più recente di due settimane).

+0

ma è ancora possibile Proprio come GUID e UUID –

3

Sono abbastanza sicuro che non ti devi preoccupare del tutto :)

Git usa l'hash SHA-1 per controllare i file, la probabilità di avere un conflitto di hash è quasi zero. Quindi divertiti !!

Personalmente ho fatto circa 30 impegni al giorno senza problemi.

Ma evitare i file binari di versionning :) è davvero pesante per quello che è.

3

Penso che non ci sia un limite forte al numero di commit che git può gestire, solo ciò che puoi digerire personalmente. Con progetti più grandi e più sviluppatori, vedrai più attività di quante tu non possa mai generare da solo.

È possibile mantenere un ramo secondario che si unisce a ogni settimana se lo si desidera, ma a git non interesserà mai il numero di commit che si hanno. Impazzisci finché riesci a capire cosa stai facendo. Puoi sempre differire diversi commit o usare strumenti come il bisect per capire i problemi di cronologia.