Inizia semplice

git init

Check-in anticipato, spesso il check-in

Fai semplicemente ciò che fai normalmente con qualsiasi progetto: "check-in" per ogni serie di modifiche correlate a una determinata attività o gruppo di azioni. Se utilizzi un tracker dei problemi, allora esegui il commit delle modifiche che si riferiscono a un'attività ogni volta che si trova in uno stato stabile (vedi questo SO domanda su quanto spesso impegnarsi ). Potrebbe non essere in uno stato di completamento, solo uno stabile, in cui il software non ha esito negativo o il mancato funzionamento del sito. Come Jeff Atwood dice nel suo post:

If the code isn't checked into source control, it doesn't exist. [...]

I'm not proposing developers check in broken code -- but I also argue that there's a big difference between broken code and incomplete code.

Impegna spesso, perfeziona dopo, pubblica una volta

Se il prodotto non è nemmeno vicino a uno stato lavorabile, continua semplicemente a verificare le modifiche come meglio credi, usando buon senso e buon senso per raggrupparle insieme. Non è necessario eseguire il commit di ogni singola riga di un file, cambiandone uno per uno, ma se si commette tutto come una grande porzione, sarà più difficile eseguire il rollback, se necessario.

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

Non Overthink It

I tuoi primi commit 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:

created the directory structure (yay!)

Ne fanno un esempio

Alla fine di ogni giornata, prova a generare un registro di ciò che hai fatto in base ai tuoi registri di commit. Se gli output che ottieni da git shortlog e git log NON sembrano soddisfacenti e utili , hai comunque inserito con un notevole sforzo nel progetto durante il giorno e verificato quelle modifiche, probabilmente non hai fallo bene .

• git shortlog dovrebbe essere visualizzato come una ampia panoramica di ciò che hai fatto.
• git log dovrebbe leggere come la cronologia AND storia del tuo progetto.

Quello che stai facendo è l'approccio giusto.

Stai utilizzando il controllo del codice sorgente dal primo giorno: questo ti garantirà tutto ciò che ti serve nel controllo del codice sorgente e non c'è alcun punto in cui tu possa dire:

I should be using source control but it's going to take too long to check in all of this stuff for the first time.

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 unisca a te nel progetto sarà in grado di lavorare immediatamente.