Un reflog può sostituire i tag per la contabilità?

3

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.

  1. Presumo che origin/production abbia il proprio reflog totalmente indipendente dal mio local tracking remoto production - è corretto?
  2. 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".
  3. Come ci si assicura che un reflog di origin/production non venga eliminato e continui a fornire informazioni storiche complete per tutti?
  4. Qualunque aspetto negativo o possibili problemi a cui non avessi pensato?
posta Kos 09.10.2013 - 11:20
fonte

1 risposta

2

Il problema principale è che il reflog è una cosa locale e mai propagata ovunque. Quindi i dati sarebbero un po 'difficili da ottenere.

Un'alternativa di tag che mi viene in mente è un ramo con sottoprogetto. Git tree può contenere un link a un commit. Quindi puoi creare un repository sopra il progetto attuale e quando lo fai, esegui il commit con la corretta revisione del sottomodulo. Non sono sicuro che sia possibile avere una parte laterale del sottoprogetto incluso tramite symlink. Sono sicuro che sarebbe possibile scrivere un'utilità per la creazione di tali revisioni nel repository senza avere effettivamente un albero di lavoro (git crea commit dallo stato di solo indice e puoi manipolare l'indice direttamente tramite i comandi e puoi dire git per usare diversi file di indice). Ci vorrebbe un po 'di lavoro però.

    
risposta data 09.10.2013 - 13:48
fonte

Leggi altre domande sui tag