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/productionabbia 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
productionlocale 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/productionreflog, corretto?
Vorrei mantenere invariato il "1 deployment = 1 record". - Come ci si assicura che un reflog di
origin/productionnon venga eliminato e continui a fornire informazioni storiche complete per tutti? - Qualunque aspetto negativo o possibili problemi a cui non avessi pensato?