sfondo

Ho usato VCS (principalmente git) in passato per gestire molti progetti esistenti e funziona benissimo. In genere con un progetto esistente, verificherei ogni modifica apportata al codice che ottimizza o modifica la funzionalità generale (sai cosa intendo, in passaggi adeguati, non ogni singola riga che cambio).

Problema

Una cosa in cui non ho avuto tanta pratica è la creazione di nuovi progetti. Sto per iniziare un mio nuovo progetto che probabilmente crescerà abbastanza grande, ma sto scoprendo che c'è molto da fare e molto cambiando nei primi giorni / ore / settimane / periodo fino a quando il prodotto non funziona effettivamente nella sua forma più semplice.

C'è qualche punto in me che controlla ogni fase del processo come farei con un progetto esistente? Non sto infrangendo il progetto con le modifiche apportate dal momento che non funziona ancora. Al momento sto semplicemente usando VCS come backup alla fine di ogni giorno, quando lascio il computer.

I miei primi impegni erano cose come "Struttura di directory di base in atto" e "Tabelle DB create". Come dovrei usare un VCS all'avvio di un nuovo progetto?

Inizia semplice

git init

Check-in anticipato, check-in spesso

Fai semplicemente quello che fai normalmente con qualsiasi progetto: "controlla" per ogni serie di modifiche che si riferiscono a un particolare compito o gruppo di azioni. Se si utilizza un tracker dei problemi, eseguire il commit delle modifiche relative a un'attività ogni volta che si trova in uno stato stabile (vedere questa domanda SO sulla frequenza con cui eseguire il commit ). Potrebbe non essere in uno stato di completamento, ma solo stabile, in cui il software non viene eseguito o il sito non viene eseguito. Come dice Jeff Atwood nel suo post:

Se il codice non è archiviato nel controllo del codice sorgente, non esiste. [...]

Non sto proponendo agli sviluppatori di verificare il codice non funzionante, ma sostengo anche che esiste una grande differenza tra codice non funzionante e codice incompleto.

Commetti spesso, perfeziona più tardi, pubblica una volta

Se il prodotto non è nemmeno vicino a uno stato praticabile, continua a controllare le modifiche come ritieni opportuno, usando il buon senso e il buon senso per raggrupparle. Non è necessario eseguire il commit di ogni singolo cambio di riga uno alla volta, ma il commit di tutto come un grosso blocco renderà più difficile il rollback, se necessario.

Alla fine, il tuo VCS è qui per aiutarti . Quindi aiuta il tuo VCS ad aiutarti !!

Non pensarci troppo

I tuoi primi impegni andavano bene. Non pensarci troppo. La cosa più importante è che sono registrati. Se guardi tutti i progetti open source esistenti online che sono partiti da zero e non da una base di codice esistente, hanno come prima revisione qualcosa di simile a:

creato la struttura delle directory (yay!)

Trasformalo in un'abitudine

Alla fine di ogni giornata, prova a generare un registro di ciò che hai fatto in base ai registri di commit. Se gli output da cui si ottengono git shortloge git logNON sembrano soddisfacenti e utili , tuttavia durante il giorno hai fatto un notevole sforzo nel progetto e hai verificato le modifiche, probabilmente non hai fatto bene .

• git shortlogdovrebbe leggere come un'ampia panoramica di ciò che hai fatto.
• git logdovrebbe leggere come la storia E la storia del tuo progetto.

Quello che stai facendo è l'approccio giusto.

Stai usando il controllo del codice sorgente sin dal primo giorno: questo ti assicurerà di avere tutto ciò di cui hai bisogno nel controllo del codice sorgente e non c'è nessun punto in cui puoi dire:

Dovrei usare il controllo del codice sorgente ma ci vorrà troppo tempo per controllare per la prima volta tutte queste cose.

Questo è un grosso ostacolo per le persone che arrivano in ritardo al controllo del codice sorgente in quanto pensano che sia "troppo difficile" da usare. Iniziando presto e apportando modifiche spesso hai ridotto questo ostacolo a un piccolo passo e chiunque altro si unirà a te nel progetto sarà in grado di mettersi subito al lavoro.