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:
-
Riscrivi la cronologia. Posso usare
git rebase --interactive --preserve-merges
. Quindi aggiungi le informazioni sul biglietto al messaggio. -
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)