Devi impegnarti non appena hai completato una "unità" ragionevole.

Che cos'è un'unità? Dipende da cosa stai facendo; se stai creando un progetto di Visual Studio, ad esempio, commetti la soluzione subito dopo la sua creazione, anche se non contiene nulla.

Da lì in poi, continua a impegnarti il più spesso possibile, ma continua a commettere solo "unità" completate (ad esempio classi, configurazioni, ecc.); fare così renderà la tua vita più facile se qualcosa va storto (puoi ripristinare un piccolo insieme di modifiche) e ridurrà la probabilità di conflitti.

Per quanto mi riguarda, il repository di controllo del codice sorgente fa parte della configurazione di base del progetto, quindi mi impegno subito dopo aver generato il mio progetto vuoto.

Ieri

... in alternativa, se non sei in grado di viaggiare nel tempo ...
(forse la tua auto non può arrivare a 88 miglia all'ora, o il tuo condensatore di flusso è appena scattato)

Ora

I nuovi progetti dovrebbero essere commessi sul posto sanguinante, è pazzesco non farlo, e i sistemi DVCS contemporanei hanno rimosso ogni possibile scusa per evitare i commit : git init . ; git add * ; git commit -m initial-commit ora, prima che sia troppo tardi, poiché potrebbe già essere.

Una domanda più ragionevole, discutibile, avrebbe potuto essere: "Quando dovrei unire il mio commit a un controllo sorgente condiviso su un team gestito repository su un progetto stabilito ? " (nota gli aggettivi, gli aggettivi sono importanti) E ho la sensazione che molte altre risposte stiano effettivamente cercando di rispondere a questo.

Il tuo ramo personale dovrebbe essere impegnato a come un matto , almeno una volta al giorno , prima di andare a dormire. Potresti semplicemente svegliarti la mattina dopo e scoprire che non hai idea di cosa diavolo stavi facendo, la notte precedente. Il VCS dovrebbe coprirti da questo e avere la possibilità di eseguire il rollback su una sottovoce versione di una sotto-versione molto recente che si compila bene, senza problemi, e / o superare i test potrebbe essere la soluzione migliore.

Direi di impegnarti il prima possibile. Lo scopo principale del controllo del codice sorgente è quello di tornare indietro nel caso in cui qualcosa vada storto, e questo risuona con la pratica di "impegnarsi presto e spesso".

Personalmente, il mio primo commit contiene in genere solo il file .gitignore (o equivalente) con pochi filtri che so saranno necessari, come *. py [co] per Codice Python L'impostazione di base del progetto e / o il primo prototipo più semplice è ciò che di solito segue.

Il primo commit può essere un file README con un solo riepilogo di riga del progetto, o abbastanza informazioni sulla prima pietra miliare del progetto. Gli argomenti generali possono anche includere:

• Introduzione
• Descrizione del progetto
• Struttura del progetto
• Convenzioni di codifica
• Istruzioni su come:
  • costruire
  • test
  • deploy
• Problemi noti e soluzioni alternative
• elenco di cose
• Termini di utilizzo

La pratica di aggiornare il README prima di apportare modifiche a un progetto viene anche definita Readme Driven Development e ti consente di riflettere sui cambiamenti prima di investire tempo per apportare tali modifiche.

Chiunque voglia contribuire o utilizzare questo software inizierà quindi con il README.

Se hai svolto un lavoro che non vorresti perdere, dovrebbe essere nel tuo sistema di controllo del codice sorgente.

Questo vale certamente per i sistemi distribuiti come Git. Se stai usando un sistema centralizzato, e l'unico modo per controllare qualcosa è renderlo visibile a tutti , potresti voler tenere a bada - o potresti considerando la possibilità di configurare il tuo repository git locale e di inviarlo al sistema centralizzato quando sei pronto.

La mia regola empirica è di fare il check-in una volta che il mio file di soluzione (o altro pezzo di script di costruzione) è stato eseguito, anche se contiene alcuni file vuoti. È una buona pratica per quando più di una persona sta lavorando al progetto. Quel file tende ad avere i peggiori problemi di unione all'inizio, dal momento che le persone aggiungono cose al progetto, quindi è necessario impegnarsi presto e spesso.

Anche se sei l'unico a lavorare sul progetto e ha solo un file, trovo più semplice seguire lo stesso flusso di lavoro e salvare il pensiero per il problema in questione.

Non sicuro se è stato menzionato.

Ma assicurati che ciò che esegui si esegue / compila! Quindi nessun errore di sintassi, ecc.

Niente di più frustrante del controllo del codice che è stato rotto.

Un altro punto di vista più correlato al testing del software (approccio TDD) verrebbe commesso non appena si avessero nuovi casi di test in verde. Ciò significherebbe che hai una nuova "unità" di codice completata.

Poco prima di fare qualcosa di sciocco.

Per quelli di noi senza poteri magici, questo significa poco e spesso.

Se lavori da solo, fallo ogni volta che prendi un drink o altro.

Se lavori in una squadra, probabilmente devi assicurarti che la cosa compili, in modo che se qualcun altro arriva l'ultima volta, non otterrà un sacco di errori. Ma a parte questo, per quanto puoi.

Circa 2 ~ 3 ore nel progetto.

Sto scherzando. Non c'è una buona risposta adatta a tutte le situazioni. Prima di tutto, se si dispone di un sistema di controllo della versione distribuito (come git o Mercurial), il commit sul repository locale non preserverà i dati in caso di errore irreversibile. Ma un repo remoto privato potrebbe costarti denaro, ad es. su github. Conserverai la cronologia dei commit, ma nella mia esperienza non ne avrai bisogno finché il tuo progetto non sarà un po 'avanzato.

Inoltre, probabilmente non vorrai avere troppo tempo all'inizio, specialmente se stai spostando file in giro. Commettere cambiamenti sarà un peso se solo piccolo. Potresti persino decidere di buttare via la cosa. Ma se perdi delle modifiche che non sono banali da replicare, ti mancherai di aver fatto una copia di backup e i sistemi di controllo delle versioni diventeranno sistemi di backup estremamente preziosi.

Alcune persone oggigiorno usano DropBox o simili per memorizzare il loro codice. Potrebbe essere un buon compromesso all'inizio di un progetto poiché richiede zero sforzi per l'impostazione. È tuttavia un'abitudine barbarica nello sviluppo di software serio, specialmente se più persone stanno toccando il codice allo stesso tempo.

Quindi, tendo ad impostare il controllo della versione ogni volta che ho qualcosa che è prezioso, cioè non banale da replicare. Il valore è soggettivo (e dipende dalle proprie capacità), quindi dovrai esprimere il tuo giudizio. A quel punto immagazzino un secondo repository su un disco esterno, o su github se si tratta di un progetto pubblico o il mio account di pagamento lo terrà.

Molte persone hanno già risposto "subito" e io sono al 100% d'accordo. Mi piace anche il suggerimento di Xion per iniziare con i pattern di ignoranza di VCS (cioè .gitignore o equivalente).

Suppongo che sia abbastanza d'accordo sul fatto che non ci siano aspetti negativi dei primi impegni. Mi piacerebbe aggiungere lati positivi:

• È meno probabile che tu commetta cose che hai scelto di scartare, ma questo è ancora intorno. Quando avvio un nuovo sviluppo, eseguirò il codice e discuterò rapidamente le cose, e quando mi impegnerò in seguito, quando ci sono già un sacco di file, ho accidentalmente commesso roba solo per cancellarla nel prossimo commit. Questo, al contrario di piccoli, o addirittura vuoti, commette, è vero rumore nella storia.
• Se sei un tipo sistematico e hai i primi passi tipici nei tuoi progetti, avere questi come punti di commit può essere istruttivo per te o per gli altri, e potrebbe anche fornire un'opportunità per separarsi a un certo punto e creare un riutilizzabile stub del progetto. Ho lavorato a progetti basati su Maven in cui ciò è stato utile (perché nella creazione di un progetto Maven, alcuni piccoli primi passi possono già definire una base piuttosto sostanziale, e mentre questi passaggi non sono molto utili per fare , possono richiedere abbastanza pensieri per garantire la riusabilità).

Può dipendere dal VCS che si sta utilizzando.

Con Git, commetto una directory vuota (o con un file README quasi vuoto). Il punto è che posso tornare indietro e resettare il mio ramo su quello stato vuoto se voglio ricominciare da capo mentre sono ancora all'inizio del processo di sviluppo (prima di spingere verso monte). Quindi impegnerei i miei file "generati" (ad esempio la soluzione di Visual Studio). Poi, quando sto codificando, comincerò a commettere ogni unità come faresti normalmente.

Con SVN, stai spingendo verso l'alto con ogni commit in modo da non avere il lusso di ricominciare da capo come fai con Git. In questo caso, potrebbe non essere vantaggioso eseguire il commit in anticipo se pensi che durante il processo dovrai eseguire un importante revamping. Tuttavia, sarà la persona che codifica.

Quando avvio un nuovo progetto, di solito inizio cominciando quello prima che qualsiasi codice sia stato aggiunto. Una regola generale che ho sempre seguito è la seguente: se il PC si blocca e cancella tutti i dati, quale codice preferiresti non dover scrivere dalla memoria. Dieci anni fa, prima del TDD e di una migliore pratica di programmazione, ero abbastanza ottimista su ciò che potevo ricordare. Ora, tendo ad essere più cauto. Come molti altri utenti hanno detto che si impegnano presto e si impegnano spesso. Non stai perdendo nulla facendolo.

Lavoro per conto mio per la maggior parte del tempo, quindi devo confessare che mi sto rilassando, ma generalmente mi impegno prima di andare a casa. In questo modo se non lo faccio domani, i miei colleghi possono riprendere da dove ho lasciato.

Attualmente sto usando Tortoise / SVN al lavoro.

Impegna il progetto vuoto subito. Continua a impegnare più volte all'ora a lavorare sul progetto. Commit anche se il codice non viene compilato. Contrassegno tali commit con "WIP" nel massaggio di commit per tenerne traccia.

Ho anche uno script che impegna automaticamente tutti i miei progetti ogni 10 minuti a un repository di backup, nel caso in cui dimenticassi di eseguire il commit manualmente. Chiamiamolo buffer di annullamento con backup cloud.

Effettua il check-in (ovvero. invia ) il progetto a un repository di team quando hai bisogno che il tuo team visualizzi il tuo codice. Probabilmente prima che il tuo codice sia pronto per essere visto dal tuo team, se sei come me.

Se vuoi essere gentile con la tua squadra, squash i tuoi commit prima di inviarli al repository del team.

Ho esaminato tutti gli articoli e penso che abbiamo già molte buone soluzioni, ma mi piacerebbe condividere la mia metodologia con te.

Mentre si lavora sulla creazione del framework (direttamente da zero), molte modifiche avranno luogo per ogni modulo fino a quando il modulo sarà completato o finalizzato. Quindi ho sempre 2 posizioni una si chiama DYNAMIC e l'altra STATIC. Quando i cambiamenti sono in corso e il framework non è ancora stato finalizzato, è stato commesso in posizione DYANMIC e una volta completato e finalizzato, lo sposto nella posizione STATIC. Quindi ho un controllo del codice sorgente completo.

Grazie

Con qualsiasi applicazione, dovrai dedicare un po 'di tempo alla progettazione dei componenti. Dovresti conoscere, in modo approssimativo o completo, i tuoi spazi nome, progetti, riferimenti esterni, librerie di terze parti ecc.

Se sei in una squadra, ti suggerirei di guidare, o chiunque sia stato scelto, per creare il progetto base, ottenere il set di dipendenze e controllare lo scheletro (il fondamento sul quale il tuo progetto sarà costruito).

Inoltre, assicurati di avere le tue attività, rilascio, trunk, ecc. specificate in rami prima di effettuare il check in in modo che il tuo processo sia solido.

Se stai lavorando su una nuova "attività" per un progetto già in corso e sei nel tuo ramo attività, esegui i tuoi check-in notturni in modo da preservare il tuo lavoro.

Di solito mi registro ogni volta che aggiungo qualcosa di nuovo, ma provo a separare le cose in commit discreti.

Ciò significa che se aggiungo una nuova dipendenza, apporto le modifiche finché non vengono compilate, o sono abbastanza grandi da perdere tempo per eseguirle nuovamente da zero. Se ho un compito più grande, provo a impegnarmi più volte, quando ha senso (una volta per funzione, ogni volta che lo faccio compilare ed eseguire con successo, ecc.)

Commetto anche quando voglio un punto di backup (cioè "se quello che provo ora non funzionerà o diventerà troppo complicato, voglio tornare al codice come è adesso", o quando qualcuno mi chiede di lasciar perdere quello che sto facendo e risolvere alcuni problemi urgenti).

Se si utilizza un sistema di controllo del codice sorgente centralizzato, non è possibile eseguire il commit arbitrariamente per i punti di backup, poiché un commit che non esegue la compilazione / il lavoro interessa tutti nel proprio team.

Di solito quando inizio ad aggiungere il codice boilerplate (ad esempio, aggiungi una nuova webapp in un sito Web django), impegno tutte le operazioni che faccio.

Se seguo un tutorial per generare / scrivere codice, utilizzo i nomi dei passaggi nel tutorial per i messaggi di commit. In questo modo, posso diff revisioni e vedere cosa ha fatto un passo del tutorial, in qualsiasi momento successivo.

Let's say, for example, I have a project which consists of a single code file. It will take about 10 lines of boilerplate code, and 100 lines to get the project working with extremely basic functionality (1 or 2 features).

Dipenderà da quanto sia difficile aggiungere cose:

• se fosse banale aggiungere il codice della piastra della caldaia, vorrei aggiungerlo e commetterlo prima di iniziare sull'altro codice (in questo modo, se faccio un errore o introduco uno strano bug più tardi, posso semplicemente tornare al codice boilerplate e ricominciare).

• Se il codice fosse non banale, mi impegnerei ogni volta che aggiungo qualcosa di nuovo (ovunque tra due righe di codice modificate, fino a un centinaio).