Non sono mai sicuro quando un progetto sia abbastanza lontano da impegnarsi per il controllo del codice sorgente. Tendo a rimandare l'impegno fino a quando il progetto non sarà "completo dal punto di vista del quadro" e da quel momento in poi impegnerò principalmente le funzionalità. (Non ho fatto alcun progetto personale abbastanza grande da avere un framework di base troppo grande per questo.) Ho la sensazione che questa non sia la migliore pratica, anche se non sono sicuro di cosa potrebbe andare storto.

Diciamo, ad esempio, che ho un progetto che consiste in un singolo file di codice. Ci vorranno circa 10 righe di codice boilerplate e 100 righe per far funzionare il progetto con funzionalità estremamente basilari (1 o 2 funzionalità). Devo prima fare il check-in:

1. Il file vuoto?
2. Il codice del boilerplate?
3. Le prime caratteristiche?
4. Ad un altro punto?

Inoltre, quali sono i motivi per effettuare il check-in in un punto specifico?

Dovresti impegnarti non appena avrai completato una "unità" ragionevole.

Cos'è un'unità? Dipende da cosa stai facendo; se stai creando un progetto Visual Studio, ad esempio, esegui il commit della soluzione subito dopo la sua creazione, anche se non contiene nulla.

Da quel momento, continua a impegnarti il ​​più spesso possibile, ma impegna ancora solo "unità" completate (ad es. Classi, configurazioni, ecc.); farlo ti renderà la vita più semplice se qualcosa va storto (puoi annullare una piccola serie di modifiche) e ridurrà la probabilità di conflitti.

Per quanto mi riguarda, il tuo 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 si è appena spezzato)

Adesso

Nuovi progetti dovrebbero essere impegnati sul posto insanguinato, è pazzesco non farlo, e i sistemi DVCS contemporanei hanno appena rimosso ogni possibile scusa per evitare impegni : git init . ; git add * ; git commit -m initial-commitora, prima che sia troppo tardi, come potrebbe già essere.

Un'altra domanda sensata, discutibile, potrebbe essere stata: "Quando dovrei unire i miei commit a un controllo sorgente condiviso su un repository gestito dal team su un progetto stabilito ?" (nota gli aggettivi, gli aggettivi sono importanti) E ho la sensazione che la maggior parte delle altre risposte stiano effettivamente cercando di rispondere.

Il tuo ramo personale dovrebbe essere impegnato come pazzo , almeno una volta al giorno , prima di coricarsi. Potresti svegliarti la mattina dopo e scoprire di non avere idea di cosa diavolo stavi facendo, la notte precedente. Il VCS dovrebbe coprirti da questo, e avere l'opportunità di tornare a una versione molto recente di una sub-versione che si compila bene, funziona senza intoppi e / o supera i test potrebbe essere la tua migliore opzione.

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

Personalmente, il mio primo commit in genere contiene solo il file .gitignore (o equivalente) con pochi filtri che so saranno necessari, come * .py [co] per il codice Python. L'installazione 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 una riga del progetto o informazioni sufficienti 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
  • schierare
• Problemi noti e soluzioni alternative
• lista di cose da fare
• Condizioni d'uso

La pratica di aggiornare il file README prima di apportare modifiche a un progetto è anche definita Readme Driven Development e ti consente di riflettere sulle modifiche prima di investire tempo per apportarle.

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

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

Questo si applica certamente a sistemi distribuiti come Git. Se stai utilizzando un sistema centralizzato e l'unico modo per archiviare qualcosa è renderlo visibile a tutti , potresti voler tenere a bada o potresti prendere in considerazione la possibilità di configurare il tuo repository git locale e inviarlo al centralizzato sistema quando sei pronto.

La mia regola empirica è quella di effettuare il check-in una volta che il mio file di soluzione (o altro pezzo di script di build) è stato eseguito, anche se contiene alcuni file vuoti. È buona pratica quando più di una persona sta lavorando al progetto. Quel file tende ad avere i problemi di fusione peggiori inizialmente poiché le persone stanno aggiungendo cose al progetto, quindi è necessario impegnarsi presto e spesso.

Anche se sei l'unico che lavora al progetto e ha solo un file, trovo più facile seguire lo stesso flusso di lavoro e salvare il pensiero per il problema in questione.

Non sono sicuro se è stato menzionato.

Ma assicurati che ciò che commetti venga eseguito / compilato! Quindi nessun errore di sintassi, ecc.

Niente di più frustrante del checkout del codice non funzionante.

Un altro punto di vista più legato ai test del software (approccio TDD) sarebbe impegnarsi non appena avrai nuovi casi di test in verde. Ciò significherebbe che hai una nuova "unità" di codice completata.

Poco prima di fare qualcosa di stupido.

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

Se lavori da solo, fallo ogni volta che prendi un drink o qualsiasi altra cosa.

Se lavori in una squadra, probabilmente devi assicurarti che la cosa si compili, in modo che se qualcun altro arriva all'ultimo, non riceveranno un sacco di errori. Ma a parte questo, il più possibile.

Circa 2 ~ 3 ore nel progetto.

Solo scherzando. Non esiste una buona risposta adatta a tutte le situazioni. Prima di tutto, se hai un sistema di controllo della versione distribuito (come git o Mercurial), il commit nel tuo repository locale non preserverà i tuoi dati in caso di errore catastrofico. Ma un repository remoto privato può costarti denaro, ad esempio su Github. Conserverai la cronologia dei commit, ma nella mia esperienza non ne avrai bisogno fino a quando il tuo progetto non sarà un po 'avanzato.

Inoltre, probabilmente non vuoi troppo sfornare all'inizio, specialmente se stai spostando i file. Commettere cambiamenti sarà un peso se non di poco conto. Puoi anche decidere di buttare via la cosa. Ma se perdi modifiche che non sono banali da replicare, ti perderai dopo aver fatto una copia di backup e i sistemi di controllo della versione creano sistemi di backup estremamente preziosi.

Al giorno d'oggi alcune persone usano DropBox o simili per memorizzare il loro codice. Potrebbe essere un buon compromesso all'inizio di un progetto poiché non è necessario alcuno sforzo per istituire. È comunque un'abitudine barbarica nello sviluppo di software serio, specialmente se diverse persone toccano il codice contemporaneamente.

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

Molte persone hanno già risposto "Immediatamente" e sono d'accordo al 100%. Mi piace anche il suggerimento di Xion di iniziare con gli schemi di ignorare del VCS (cioè .gitignoreo equivalenti).

Immagino sia abbastanza concordato sul fatto che non ci sono aspetti negativi nei primi impegni. Vorrei aggiungere degli aspetti positivi:

• È meno probabile che commetti cose che hai scelto di scartare ma che continuano a persistere. Quando inizio un nuovo sviluppo, codificherò e discraderò rapidamente le cose, e quando commetterò più tardi, quando ci sono già un sacco di file, ho commesso accidentalmente cose solo per cancellarle nel prossimo commit. Questo, al contrario di piccoli, o addirittura vuoti, è un vero rumore nella storia.
• Se sei un tipo sistematico e hai i primi passi tipici nei tuoi progetti, avere quelli come punti di commit può essere istruttivo per te o per altri, e potrebbe anche fornire l'opportunità di ramificarsi ad un certo punto e creare uno stub riutilizzabile del progetto. Ho lavorato su progetti basati su Maven in cui questo è stato utile (perché nella creazione di un progetto Maven, alcuni piccoli primi passi possono già definire una base abbastanza sostanziale e, sebbene quei passaggi non siano molto da fare , possono richiedere abbastanza pensiero per giustificare riusabilità).

Può dipendere dal VCS in uso.

Con Git, eseguo il commit di una directory vuota (o con un file README quasi vuoto). Il punto è che posso tornare indietro e ripristinare il mio ramo a quello stato vuoto se voglio ricominciare completamente mentre sono ancora all'inizio del processo di sviluppo (prima di spingere a monte). Vorrei quindi eseguire il commit dei miei file "generati" (ad esempio la soluzione di Visual Studio). Quindi, quando sto effettivamente programmando, comincerò a impegnare ogni unità come faresti normalmente.

Con SVN, stai spingendo a monte con ogni commit in modo da non avere il lusso di ricominciare da capo come fai con Git. In questo caso, potrebbe non essere utile impegnarsi in anticipo se si pensa che si effettuerà un importante rinnovamento all'inizio del processo. Questo dipenderà dalla codifica della persona però.

Quando inizio un nuovo progetto di solito comincio a commetterlo prima che sia stato aggiunto qualsiasi codice. Una regola generale che ho sempre seguito è: se il tuo PC si è bloccato e cancellato tutti i tuoi dati quale codice preferiresti non dover scrivere dalla memoria. Dieci anni fa, prima del TDD e delle migliori pratiche di programmazione, ero piuttosto ottimista su ciò che ricordavo. Ora tendo ad essere più cauto. Come molti altri manifesti hanno detto commettere presto e commettere spesso. Non stai perdendo nulla facendolo.

Sto lavorando da solo per la maggior parte del tempo, quindi devo confessare che mi sto rilassando, ma generalmente mi impegno prima di tornare a casa. In questo modo, se non arrivo domani, i miei colleghi potranno riprendere da dove avevo interrotto.

Attualmente sto usando Tortoise / SVN al lavoro.

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

Ho anche uno script che esegue automaticamente il commit di tutti i miei progetti ogni 10 minuti in un repository di backup, nel caso in cui dimentichi di impegnarmi manualmente. Chiamiamolo il mio buffer di annullamento supportato dal cloud.

Effettua il check-in (ovvero push ) del progetto in un repository team quando hai bisogno del tuo team per vedere il tuo codice. Che è probabilmente prima che il tuo codice sia pronto per essere visto dal tuo team, se sei qualcosa come me.

Se vuoi essere gentile con la tua squadra, elimina i tuoi impegni prima di spingerli al repository della squadra.

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

Mentre si lavora sulla creazione del framework (da zero), verranno apportate molte modifiche per ciascun modulo fino a quando il modulo non viene completato o finalizzato. Quindi ho sempre 2 posizioni, una è chiamata DINAMICA e l'altra è STATICA. Quando le modifiche sono in corso e il framework non è ancora finalizzato, è stato eseguito il commit nella posizione DYANMIC e una volta completato e finalizzato, lo sposto nella posizione STATIC. Quindi ho un controllo completo del codice sorgente.

Grazie

Con qualsiasi applicazione, trascorrerai un po 'di tempo a progettare i componenti. Dovresti conoscere, approssimativamente o in dettaglio, spazi dei nomi, progetti, riferimenti esterni, librerie di terze parti ecc.

Se fai parte di una squadra, suggerirei la tua guida, o chiunque sia scelto, per creare il progetto di base, ottenere le dipendenze e controllare quello scheletro (fondamento su cui sarà costruito il tuo progetto).

Inoltre, devi assicurarti di avere i rami di attività, rilascio, trunk, ecc. Specificati prima di effettuare il check-in in modo che il processo sia solido.

Se stai lavorando a una nuova "attività" per un progetto che è già in corso e sei nel tuo ramo di attività, fai i check-in notturni in modo da preservare il tuo lavoro.

Di solito faccio il check-in 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 fino a quando non vengono compilate o sono sufficientemente grandi da perdere tempo a rifarle da zero. Se ho un compito più grande, provo a impegnarmi più volte, quando ha senso (una volta per funzione, ogni volta che lo compilo e lo eseguo correttamente, ecc.).

Mi impegno anche quando desidero un punto di backup (ovvero "se ciò che provo ora non funziona o diventa troppo complicato, voglio tornare al codice così com'è ora", o quando qualcuno mi chiede di eliminare ciò che sono fare e risolvere alcuni problemi urgenti).

Se si utilizza un sistema centralizzato di controllo del codice sorgente, non è possibile eseguire il commit arbitrario per i punti di backup, poiché un commit che non viene compilato / funzionante influisce su tutti i membri del team.

Di solito quando inizio ad aggiungere il codice boilerplate (ad es. Aggiungo una nuova webapp in un sito Web django), commetto ogni operazione che faccio.

Se seguo un'esercitazione per generare / scrivere codice, utilizzo i nomi delle fasi nell'esercitazione per i messaggi di commit. In questo modo, posso differire le revisioni e vedere cosa ha fatto un passaggio del tutorial, in qualsiasi momento successivo.

Diciamo, ad esempio, che ho un progetto che consiste in un singolo file di codice. Ci vorranno circa 10 righe di codice boilerplate e 100 righe per far funzionare il progetto con funzionalità estremamente basilari (1 o 2 funzionalità).

Dipenderebbe da quanto sia difficile aggiungere le cose:

• se fosse banale aggiungere il codice della piastra della caldaia, lo aggiungerei e lo impegnerei subito prima di iniziare con l'altro codice (in questo modo, se commetto un errore o introduco uno strano bug in seguito, posso semplicemente tornare al codice della piastra della caldaia e iniziare ancora).

• Se il codice fosse non banale, mi impegnerei ogni volta che aggiungessi qualcosa di nuovo (ovunque tra le due righe di codice cambiate, a circa cento).