Gestione dei file di "backup" con Git

Senza troppi problemi, l'opzione più semplice è quella di impegnare l'intera cartella del progetto come prima commit, quindi eliminare tutti i file backup e infine eseguire il commit della copia "ripulita" . In questo modo puoi accedere alle copie dei vecchi file ogni volta che vuoi, ma normalmente non ingombrano la tua directory di lavoro.

Se vuoi davvero provare a ricostruire la tua storia, potresti provare ad utilizzare alcune delle tecniche di lightning talk di Charles Bailey in questi anni Conferenza ACCU :

• Massaggio di Hunks: The Awesome Power di git add -p (p89).

Non metterli affatto! Non conosco il modo esatto in Git, ma in SVN semplicemente non li aggiungi al repository. Con un sistema di controllo della versione non hai bisogno della un'altra cronologia - aggiunge solo complessità.

Dovresti sempre impegnarti a controllare i sorgenti il prima possibile. Generalmente questo è non appena hai un codice funzionante. Più spesso esegui il commit, meno è probabile che siano necessari altri file di cronologia.

Se sai quali backup sono stati eseguiti quando, puoi eseguire quanto segue (manualmente :/ ):

1. Crea un repository git e commetti la prima versione dei file
2. Copia la successiva versione di backup più recente dei file sugli originali e li commette.
3. Continua fino alla versione più recente.

Contro: richiede molto tempo se si dispone di molti file

Pro: puoi disegnare la tua storia come ti sembra opportuno. Più aggiornamenti di file possono essere in un commit, o ogni file può avere il proprio commit per aggiornarlo, e tutto ciò che è intermedio. Si ottiene una cronologia completa, pulita e completa e tutte le versioni di backup sono archiviate ordinatamente nel controllo del codice sorgente. Puoi fare esattamente ciò che @Mark suggerisce nella sua risposta, ma è ancora più fine di quanto non facciano i commit basati su file / backup.