Linee guida sull'utilizzo del repository di codici

Se stai usando git ti consiglio di leggere questo post "Un modello di branching Git di successo "
Tuttavia, se non stai usando git, credo che tu possa ancora trovare alcune idee molto interessanti.

Un buon punto di partenza sarebbe questa guida e manuale delle migliori pratiche , che non si applica solo per SCM Perforce.

Poi c'è una mandria di domande simili su stackoverflow.com.

È una buona domanda, ma qui non c'è un proiettile d'argento. Permettetemi di condividere alcune linee guida personali che sembrano mantenersi in buona posizione nell'ultimo decennio:

1. È una buona idea mantenere rami di produzione e sviluppo separati. Il ramo di produzione è il tuo pane e burro immediato, è qui che si svolgono le correzioni rapide: la produzione e lo sviluppo vengono mantenuti in diversi rami in modo che i normali check-in degli sviluppatori per alcune versioni future non compromettano i tuoi attuali impegni dei clienti.
2. Avere un unico ramo di produzione. Non avere filiali di produzione specifiche del cliente (a meno che tu non stia dormendo troppo e desideri rimanere sveglio di notte)
3. Se sviluppatori o gruppi stanno lavorando su idee disparate, hanno filiali specifiche per lo sviluppo.
4. Unisci le filiali con largo anticipo (2-3 settimane) prima di una versione principale. Di solito unisco le modifiche alla produzione, ma ci sono persone che creano un nuovo ramo di produzione con tutte le versioni principali, quindi la tua chiamata è lì.

Concettualmente, la maggior parte dei sistemi di controllo del codice sorgente sono simili. Ci sono delle eccezioni - come è stato detto, i modelli di ramificazione tendono ad essere piuttosto diversi nei sistemi distribuiti rispetto alla varietà non distribuita.

Joel Spolsky ha scritto un'utile introduzione al modo di fare Mercurial: Hg Init . Vale la pena leggerlo, anche se non hai intenzione di usare Mercurial.

Tendo ad evitare i rami di sviluppo il più possibile. Ciò impone l'unione anticipata del nuovo codice. Impegnarsi presto; commettere spesso. Questo si adatta bene ad un ambiente di costruzione continuo o frequente.

I rami di sviluppo sono meglio conservati per modifiche sperimentali o architettoniche che potrebbero non essere accettate. Unirli nuovamente allo sviluppo può essere problematico.

I branch ogni versione di produzione dallo sviluppo. Le modifiche sul ramo sono gestite. Hanno quasi sempre bisogno di tornare allo sviluppo. Tuttavia, la produzione potrebbe ottenere una soluzione rapida e una correzione più ampia potrebbe andare in sviluppo.

Alcuni progetti in un ramo per correzione, quindi unirli singolarmente nel codice di sviluppo. Questo può essere un problema se hai modifiche sovrapposte. È utile, se decidi di annullare un cambiamento impegnato.