Non eseguire mai il checkout del ramo di produzione
O più specificamente, non lavorare mai fuori dal ramo di produzione (è corretto controllarlo per test e / o patch). Ed ecco perché. Non sai mai quando o se ti verrà chiesto di lavorare su un altro requisito / correzione mentre stai già sviluppando qualcos'altro. Il ramo di produzione deve essere utilizzato solo per testare il codice che sta per essere pubblicato o per apportare correzioni rapide (correzioni che hanno un ciclo di sviluppo molto più breve del tempo medio tra due check-in al ramo di produzione).
Il primo approccio che hai menzionato è quello che ho osservato più comunemente nelle impostazioni aziendali. Ecco i vantaggi:
- Puoi creare il numero di rami diversi che desideri per funzioni diverse.
- Non devi perdere il lavoro se decidi di abbandonare temporaneamente l'attività o di dover lavorare su un'attività diversa per un breve periodo.
- Molti sviluppatori hanno l'abitudine di commettere i loro cambiamenti alla filiale in modo che abbiano un back-up (e di rispondere da soli "come sono ... sono arrivato qui?" Ovviamente non puoi adottare questo approccio con il ramo di produzione Se usi il sistema Perforce (so che hai detto che non lo sei), potresti essere tentato di usare la funzione shelve ma questo non ti farà uscire dalle situazioni che ho descritto in # 1 e # 2.
Alcuni consigli fuori tema su come mantenere lo sviluppo. rami
Penso che sia una buona pratica fondere regolarmente il ramo di produzione con il tuo dev. ramo in modo che non sia necessario intraprendere un massiccio processo di unione quando si decide di unire le modifiche al ramo di produzione. Un altro vantaggio di questa pratica è che se qualcuno controlla una modifica in conflitto alle tue modifiche al ramo di produzione, puoi trovarle al riguardo nel ciclo di sviluppo stesso (supponendo che tu collauda regolarmente durante lo sviluppo).
Un'altra pratica che puoi seguire per evitare di incasinare il ramo di produzione è di unire il ramo di produzione un'ultima volta con il tuo sviluppatore. ramo, prova il tuo dev. filiale completamente per risolvere / scoprire eventuali conflitti (non solo quelli che emergono come differenze di linea ma anche quelli che possono presentarsi come conflitti a livello di progettazione), e quindi unire il ramo alla produzione.
Ancora un'altra buona pratica è quella di etichettare il dev. diramazione con qualcosa che identifica l'obiettivo specifico di tale attività di sviluppo piuttosto che solo chi possiede tale sviluppo. ramo (quindi, dev_notificationEnhancement e non dev_monstertruck ).