L'impegno iniziale del progetto per il controllo del codice sorgente [duplicato]

9

Probabilmente penso troppo a questo e potrebbe non avere importanza nella portata delle cose, ma mi chiedo come le persone costruiscono le versioni iniziali dei loro progetti nel controllo del codice sorgente? Sto parlando di quando inizi con nient'altro che un'idea, quindi non bifrare un progetto esistente o altro.

  • Quando esegui i tuoi commit prima di avere una versione ufficiale o addirittura non ufficiale?
  • A che punto si avvia la ramificazione delle funzionalità o lo si fa subito?

Sono così abituato a lavorare con basi di codice esistenti che non sono sicuro di sapere se esiste un modo "migliore" per costruire una cronologia del progetto.

    
posta Andrew 01.12.2011 - 20:55
fonte

4 risposte

11

Quando esegui i tuoi commit prima di avere una versione ufficiale o addirittura non ufficiale?
Segui la filosofia di impegnarti il più spesso possibile. Uso Subversion per la maggior parte del tempo. Non appena avrò un codice che non vorrei perdere, e vorrei tornare a se rovino qualcosa, faccio il mio primo commit.

A che punto si avvia la ramificazione delle funzionalità o si fa subito a questo?
Non lo farei solo dopo la prima versione o se ci sono più sviluppatori che devono lavorare sulle stesse aree della base di codice per scopi diversi che potrebbero non essere rilasciati contemporaneamente.

    
risposta data 01.12.2011 - 21:38
fonte
2

In genere inizio solo a utilizzare un repository mercuriale locale e ad eseguire l'impostazione predefinita. Se cresce le gambe, lo sposterò al repository centrale e installerò l'integrazione continua e così.

Branching è molto più di una decisione tattica. Se lo sviluppo è lineare, rimarrò spesso predefinito fino a quando non avrò bisogno di versioni concomitanti là fuori - come qualcosa di un po 'più fisso per il QA o test di integrazione. A quel punto aggiungerò lo sviluppo a lungo termine e le filiali di rilascio.

Se il progetto richiede un po 'più di sviluppo sperimentale, userò i rami nominati per contenere gli esperimenti sin da ora. Le fusioni sono divertenti e facili in HG quindi potresti anche usarle.

    
risposta data 01.12.2011 - 21:20
fonte
2

Segui l'unità del modello di lavoro :)

Ogni volta che hai finito una parte di una funzione e il codice viene compilato , allora commetti.

Non preoccuparti dei messaggi di commit fino a quando non rilasci il codice in libertà. In questo caso, molti progetti eliminano tutta la cronologia delle revisioni e reinizializzano il repository. Allora e solo allora ha senso pensarlo troppo.

In questo modo puoi avere molti progetti per gli animali domestici e i pochi che riescono a ottenere il meglio possono essere pubblicati.

Quanto a quando utilizzare i rami direi che se sei da solo, potresti non averne bisogno. Scegli una funzione alla volta e completala.

    
risposta data 01.12.2011 - 22:51
fonte
2

Comincio inserendo un file di testo che delinea ciò che sto cercando di realizzare, o anche una bozza di questo. Continuo a commettere frequentemente fino a quando non arrivo ad un certo punto che è una pietra miliare utile - un punto per cui vale la pena tornare se vado fuori strada. A quel punto, mi dirigo e continuo lo sviluppo sul ramo. Una volta che il ramo raggiunge un traguardo utile, lo unisco e avvio un altro ramo.

Alcune persone sostengono che non ti impegni finché non viene compilato. Suppongo che tu impegni sempre su un ramo ma non si unisca alla linea principale finché non è strettamente migliore dello sviluppo mainline.

    
risposta data 02.12.2011 - 16:45
fonte

Leggi altre domande sui tag