Se stai seguendo la metodologia DVCS standard di avere un ramo di produzione e un ramo di sviluppo, sono davvero interessato a cosa fai con il ramo predefinito (mercuriale) o principale (git)?
Nota: sono davvero interessato a Mercurial in particolare, ma qualsiasi altro DVCS o solo regole generali sarebbe ok
La pratica usata da git core e dal kernel è stata documentata nella manpage di gitworkflows . Un altro flusso di lavoro più recente è il flusso di lavoro git flow . Entrambi raccomandano l'uso del master come ramo "produzione".
Do you delete it (not recommended by several guides)?
No.
Do you use it as production?
No. Una volta che uno stato del codice è ritenuto pronto per la produzione, tag git è usato per contrassegnarlo .
Do you use it as development?
Sì. Il modo standard di sviluppo Git è che ogni sviluppatore crei un ramo (localmente) e svolga compiti specifici per un'attività singola . Quindi, imita quelli che hanno presentato le presentazioni Git ...
"Crea un ramo Lavoro di lavoro Lavoro, Impegno Lavoro di lavoro, Impegno, Unione, Spinta."
Una volta che il problema è stato completato, viene unito al ramo principale e poi trasferito sul ramo principale nel repository accessibile. In sostanza - quando si visualizza il flusso di lavoro a livello di repository - avendo eseguito tutto il lavoro di sviluppo nel ramo principale / predefinito.
La mia comprensione è che il ramo predefinito di solito è "dev" e si crea un nuovo ramo per ogni versione (o tag, quindi ramo quando è necessario correggere il bug). 'Prod' è solo la tua versione più recente. Questo è il modo in cui stiamo pianificando di utilizzare Mercurial, sebbene siamo ancora in pre-release.
Concettualmente questo ha senso per me: una release è solo una certa istantanea nel tempo del tuo processo di sviluppo.
Modifica: per un take diverso, vedi Un modello di branching Git riuscito .
Mi sono posto di recente la stessa domanda.
Nel nostro progetto, manteniamo un ramo per ogni versione principale dell'applicazione. Presumo che questi siano gli stessi "rami di produzione" di cui parli. Li chiamiamo "rami di manutenzione", qui.
Il mio primo pensiero è stato quello di eliminare completamente il ramo% di% di mercurial e avere un ramo per ogni versione principale. Questo porterebbe a questa struttura:
branch tag
o v2 2.2
o | v3
| o v2 2.1
|/
o v2 2.0
|
| o v1 1.1
o | v2
| o v1
|/
o v1 1.0
|
o v1
Funziona, ma c'è un lato negativo di questo approccio: se cloni un repository come questo, un semplice default non farà nulla, poiché il ramo hg update non esiste più. Personnamente, mi aspetto di essere nell'ultimo stato di sviluppo, dopo aver eseguito un default .
Alla fine, abbiamo scelto questa struttura:
branch tag
o maintenance-V2 2.2
o | default
| o maintenance-V2 2.1
|/
o default 2.0
|
| o maintenance-V1 1.1
o | default
| o maintenance-V1
|/
o default 1.0
|
o default
Il ramo hg update è il ramo di sviluppo e l'altro è quello di manutenzione della versione. L'esecuzione di un default ti porta all'ultimo mix hg update , che in questo esempio è il prossimo V3.
come risposta qui in diversi modi, e in alcuni altri ServerFault domanda , si desidera seguire le linee guida Mercurial qui :
3 . The default branch
This is where development of new features occurs. [...]
(!) It is strongly recommended to do your primary development on the so-called 'default' branch, because it is the branch used by default in various commands such as clone.
Il resto dell'articolo spiega molto bene come gestire lo sviluppo di branching di Vs.
Leggi altre domande sui tag version-control