Sto sviluppando e mantenendo un'applicazione basata sul Web che viene utilizzata internamente nel mio lavoro. Sono l'unico sviluppatore e quindi non utilizzo realmente i rami; tutto accade sul bagagliaio. Inserisco tag in Git con data e ora e sto iniziando a passare all'utilizzo di un numero di build invece di data / ora.
Nell'istanza di produzione dell'app (che è solo un tag sul trunk), è stato scoperto un bug che deve essere risolto al più presto. Nel frattempo, ho sviluppato nuove funzionalità, ma non sono pronte per essere distribuite.
Risolvere il problema è semplice: controlla il tag in un nuovo ramo, correggi, pubblica. Tuttavia, in una situazione del genere, quale dovrebbe essere il numero di build della correzione ?
Se seguo la strategia di build esistente per incrementare un numero seriale, i miei numeri di build saranno, ad es.
1234: production
1235: development (with new features)
1236: production fix (doesn't have new features)
che non sembra avere un senso. In alternativa, l'incremento del numero di build del tag di produzione porterebbe a, ad es.
1234: production
1235: development (new features)
1235: production fix
che sconfigge lo scopo dei numeri di build (identifica in modo univoco una particolare build).
L'uso dell'ID di revisione di Git è un'altra opzione, ma non è esattamente leggibile.