Si prega di suggerire un flusso di lavoro migliore in Mercurial

Question

Sono nuovo di Mercurial e quello che sto iniziando a realizzare è che il mio flusso di lavoro di base potrebbe non essere il modo più efficiente di lavorare perché eseguo commit così frequentemente e per miglioramenti di funzionalità che sono così piccolo che quando ho bisogno di trovare qualche passo precedente per tornare a, è estremamente difficile.

Ecco cosa faccio dopo che ho creato un progetto in Mercurial e ho già completato il mio primo commit.

1. apportare alcune modifiche a un file e farlo ad uno stato in cui un piccolo miglioramento sta lavorando
2. hg commit -m "improvement A works"
3. apportare alcune modifiche allo stesso file e farlo ad uno stato in cui il successivo miglioramento minore è lavoro.
4. hg commit -m "improvement B works"
5. Verificare se tutti i miglioramenti minori si sommano a una singola funzione secondaria funzionante correttamente.
6. hg commit -m "feature A works"

Se trovo un errore che è stato fatto in "miglioramento A", apro la storia (con il plugin visiva Netbeans Mercurial) e copiare e incollare una parte del codice di nuovo nella mia versione corrente e ricomincia da lì.

Questo non sembra un buon sistema - Apprezzerei qualsiasi suggerimento.

Answer 1

Sono d'accordo con Jon sul fatto che i rami siano la soluzione, ma vorrei creare rami per le funzionalità piuttosto che per i singoli miglioramenti che costituiscono una funzionalità. Il modello di flusso di lavoro sarebbe allora questo:

1. Creare ramo per la funzione A.
2. lavoro completo per il miglioramento A e commit.
3. Lavoro completo per miglioramento B e commit.
4. Quando la funzione sembra funzionare, unire la funzione Un ramo di nuovo nel tronco.

Se si trova un errore in un miglioramento di una funzione di A, invece di ricominciare, si passa alla funzione Un ramo e procedere come segue:

1. Fix miglioramento A e commettere.
2. Unisci la funzione A al ramo.

Answer 2

È possibile isolare le modifiche per i miglioramenti in rami mantenendo un tronco stabile.
Dai uno sguardo allo Branch wiki page.

modello

flusso di lavoro potrebbe essere:

1. Creare ramo di miglioramento Un
2. lavoro completo per il miglioramento A e check
3. cambiamenti di test e si fondono di nuovo nel tronco in caso di successo
4. Creare ramo di miglioramento B
5. Lavori completi di miglioramento B e check
6. Verificare le modifiche e unirle nuovamente nel bagagliaio se riuscito

Se si riscontra un errore, è possibile abbandonare il ramo (o correggere il bug nel ramo prima di unire nuovamente il tronco).

Answer 3

Non sono d'accordo con l'approccio dei rami. Se non è necessario uno sviluppo parallelo, perché aggiungere la complessità dei rami? Non c'è niente di sbagliato nel commit di piccoli "checkpoint". I tag possono essere utilizzati per indicare commit importanti, che potrebbero essere più chiari.