La situazione: il nostro team di sviluppatori e tester sta passando da ClearCase a Git, in modo pionieristico. Mentre l'esperienza con git è limitata, c'è una certa familiarità con Linux, cygwin e msys; nessuno ha paura della linea di comando, e le persone non erano generalmente molto contente di ClearCase (anche se, naturalmente, c'era un flusso di lavoro funzionante). Abbiamo l'installazione non così rara di un repository centrale remoto che i membri del team usano per scambiare i loro contributi.
Una delle maggiori differenze tra git e Clearcase è che git memorizza le versioni dell'intero albero dei sorgenti, mentre ClearCase (di base) si concentra sui singoli file e directory. In ClearCase una cronologia dell'intero albero dei sorgenti (la sequenza delle operazioni di check-in) è praticamente impossibile da ottenere, mentre è un semplice e spesso emesso git log in git.
Come indicato nel titolo, uno dei ruoli per un sistema di controllo versione è backup. Non voglio perdere più di un giorno o più di lavoro in un crash del disco (1) , quindi controllo / spingo circa il lavoro quotidiano, anche incompleto. Con ClearCase il secondo ruolo, "pubblicazione" , è nel nostro flusso di lavoro realizzato dall'etichettatura. La "etichetta di qualità più bassa" è un'etichetta mobile che uno sviluppatore inserisce nelle versioni dei file che, come un set, sono in alcune condizioni di lavoro. Gli altri membri del team vedono solo le versioni etichettate (eccetto per quello su cui lavorano). Il check-in spesso non era un problema con questo flusso di lavoro ClearCase. Altri sviluppatori avrebbero dovuto affrontarlo solo quando hanno esaminato la cronologia dei file o l'albero delle versioni dei file. Non influenzerebbe il loro lavoro.
Con git, frequenti commit, specialmente di codice immaturo, sono un fastidio che di solito viene evitato dalla ridefinizione locale prima di premere o unire. Sfortunatamente questo rimedio non è disponibile dopo una spinta: non riesco a rebase la cronologia pubblicata (il server non consente nemmeno i push di forza). Ma devo spingere spesso per il backup. Questo enigma esiste anche se lavoro su un ramo di funzionalità, perché spingere a un repository condiviso equivale a una sorta di "pubblicazione" ancor prima che il ramo della funzione sia ufficialmente "pubblicato" unendolo nuovamente al master. Dopo l'unione, tutta la cronologia dei commit "sporca" è master inquinante.
Quindi il mio desiderio, e il requisito del team, di produrre una storia editoriale leggibile e significativa collide con la necessità di eseguire regolarmente il backup del mio lavoro. Questo è stato meno un problema in ClearCase perché i passaggi della cronologia sono per lo più nascosti e non esiste una cronologia generale dell'archivio che viene incrementata da ogni singolo commit su un file (che in realtà è un problema, ovviamente).
Come gestiscono le altre persone? Probabilmente potrei avere un secondo repo remoto privato da qualche parte su una condivisione di rete (che consentirebbe anche i push forzati) solo a scopo di backup, e quindi pubblicare sul repository del team solo dopo la reimpostazione e la lucidatura. Ma non ho mai sentito parlare di un tale flusso di lavoro, e sembra ingombrante.
È semplicemente che la maggior parte delle persone non esegue il backup spesso (ad esempio, solo ogni settimana o così)? È accettabile?
(1) E naturalmente il mio repo locale risiede sullo stesso disco dell'albero di lavoro.