che si impegnano ad aggiungere il numero / numero di ticket di tracciamento dei bug a

6

Ho commesso cambiamenti in git per un progetto negli ultimi mesi. Vorrei iniziare a integrare Trac nel mio flusso di lavoro. Generalmente, ho lo stile 'git flow' del repository git. Mantengo un master e sviluppo, e dirigo funzionalità e correzioni di bug dal ramo di sviluppo.

Vedo dalle risposte in Quale commit dovrebbe chiudere un problema Github quando più commit sono responsabili? che voglio collegare il" merge commit "al ticket.

Dato che ho già diverse funzionalità nel repository git, mi piacerebbe andare "indietro nel tempo" per associarle a un ticket che è stato inserito in Trac.

A questo punto, ho due scelte:

  1. Riscrivi la cronologia. Posso usare git rebase --interactive --preserve-merges . Quindi aggiungi le informazioni sul biglietto al messaggio.

  2. Utilizza git notes add <rev> per aggiungi una nota.

Sto cercando opinioni su quale sia l'opzione migliore. 1. mi consente di essere più in linea con gli standard defacto, mentre 2. mi consente di mantenere la gestione dei ticket separata dal repository del codice .

Ho il controllo completo sul repository, sul server Trac ecc. Sviluppatore solo, niente push (tranne che su un "backup", ma posso ricostruirlo dal locale)

    
posta user7957 02.03.2012 - 18:44
fonte

1 risposta

2

Tutti loro. Se un commit è rilevante per la correzione dei problemi X e Y, e un altro per Y e Z, devono essere entrambi contrassegnati come tali. Perché vorresti "artificialmente" ridurre il numero di commit a 1? Se Trac non lo supporta, direi che è sicuramente un bug (o "funzionalità ovvia mancante").

Per quanto riguarda la seconda parte, fallo in modo pragmatico: quale opzione è meglio supportata dagli strumenti che tu usi (o vuoi usare), tenendo conto che eventuali modifiche alla storia porteranno a lavoro extra per coloro che vogliono aggiornare il loro repo.

    
risposta data 05.03.2012 - 14:17
fonte

Leggi altre domande sui tag