Il mio repository ha un ramo production
ed è pieno di innumerevoli tag del formato production-20130101-1234
che puntano a ciò che è stato effettivamente spedito sul datetime specificato.
Penso che questa soluzione sia alquanto complicata e ingombrante e mi chiedo se i reflog salteranno qui meglio. L'obiettivo è "assicurati di poter sempre scoprire quale versione è stata distribuita e esattamente quando" .
I tag fanno il lavoro, ma i reflog suonano ancora più belli perché:
- Sono creati automaticamente,
- Consentono una buona quantità di impressionanti, come nella forma di
git checkout origin/production@{3 months ago}
.
Detto questo, non ne so molto dei reflog e non sono sicuro dei possibili aspetti negativi di tale approccio.
- Presumo che
origin/production
abbia il proprio reflog totalmente indipendente dal mio local tracking remotoproduction
- è corretto? - Se si eseguono 3 consecutivi no-ff si fondono da un ramo di integrazione al mio ramo
production
locale si creano 3 voci nel mio reflog locale, ma se si preme sul repository centrale (come parte della procedura di distribuzione) si ottiene 1 nuovo entrata nel "oracle"origin/production
reflog, corretto?
Vorrei mantenere invariato il "1 deployment = 1 record". - Come ci si assicura che un reflog di
origin/production
non venga eliminato e continui a fornire informazioni storiche complete per tutti? - Qualunque aspetto negativo o possibili problemi a cui non avessi pensato?