Dimenticando di unire le modifiche da un tronco all'altro

Question

Dimenticando di unire le modifiche da un tronco all'altro

#1 da (4 voti)
#2 da (1 voti)
#3 da (1 voti)

5

Recentemente, ho dimenticato di unire le modifiche dal trunk al nostro ramo di manutenzione. Questo ci ha permesso di ricostruire - due volte - e mettere in attesa il QA per due giorni mentre abbiamo risolto il problema.

Normalmente, quando eseguo il commit su entrambe le diramazioni, inserisco un singolo changeset nel trunk e lo unisco immediatamente al ramo di manutenzione.
Tuttavia, questa volta c'erano 12 changeset che coprivano molte modifiche alla revisione del codice e non sono riuscito a unire tutte le modifiche. Mi sono limitato a un solo cambiamento, il che mi ha completamente buttato fuori - ho pensato di ricordare che si trattava di un commit cumulativo di tutti gli altri changeset, ma non lo era.

Dopo alcune discussioni sullo sviluppo, abbiamo deciso che l'approccio migliore sarebbe stato quello di effettuare il commit 1-to-1 del ramo di manutenzione e del ramo di manutenzione, in modo da poter verificare visivamente che tutto il codice fosse presente.

C'è un modo per far rispettare i commit di changeset per una determinata versione di fix-for?
Utilizziamo JIRA , Fisheye e Crucible , e il nostro flusso di lavoro Fisheye non ti consentirà di risolvere un problema a meno che le revisioni del codice sono completi Mi piacerebbe qualcosa di simile a controlli paralleli forzati su trunk e rami di manutenzione, in base alla versione fix-for specificata nel problema.

O c'è una soluzione migliore per tutto questo casino oltre a "non farlo"?

version-control branching issue-tracking builds failure

posta mskfisher 02.06.2011 - 17:14

fonte

3 risposte

Leggi altre domande sui tag version-control branching issue-tracking builds failure

Rails: controller vs modelli che dovrebbero gestire la manipolazione dei file E 'possibile refactoring ereditarietà di composizione quando i metodi virtuali sono chiamati all'interno della classe base?

score 4 · Answer 1

Ovviamente questo funziona solo se usi git, ma ecco come mi avvicinerei ...

Ogni richiesta di funzionalità, e ogni bug, ottiene il proprio ramo localmente. Lo sviluppatore quindi fa tutte le modifiche necessarie. Al termine, rebase il ramo e unisci / dividi i commit in unità di lavoro logiche. Per piccole funzionalità e correzioni di bug, non dovrebbe essere difficile mantenerli in un singolo commit. Per caratteristiche più grandi, potresti voler avere più commit, ad es .: "Aggiungi interfaccia per pippo". "Aggiungi implementazione di foo". "Chiedi a Whizbang di usare la nuova funzionalità di foo". Il punto è mantenere tutte le linee di codice logicamente connesse in un unico commit. A quel punto, l'unità di lavoro ha uno (o un insieme) di commit. Il tuo bug tracker dovrebbe permetterti di collegare i commit ai ticket. Il bugfix ticket si collegherebbe al commit del bugfix e dovrebbe essere facile vedere che il commit è stato unito al ramo di rilascio appropriato.

score 1 · Answer 2

Al mio lavoro abbiamo un software di casa che ci aiuta a iniziare / terminare i progetti. Quando si atterra il progetto, crea un albero, applica le modifiche, quindi unisce tutte le modifiche nel trunk. (Risolvi i conflitti lì.) Quando finisci, li impegna (e cancella il tuo progetto).

Quando si avvia un progetto, si specifica se si tratta di una correzione o meno. Se si tratta di un aggiornamento rapido, quando lo si atterra crea patch sia sul trunk che sul ramo di manutenzione.

Ovviamente ora devi ricordarti di rendere il progetto un hotfix. Ma rende facile assicurarsi che un sacco di cambiamenti correlati vengano tutti commessi insieme dove devono essere.

score 1 · Answer 3

Quello che hai fatto è probabilmente il risultato di un difetto del processo che richiede di ricordarti di farlo (quindi lo fai immediatamente), senza tracciamento del fatto che è stato fatto veramente.

Domanda: puoi facilmente creare un rapporto che confermi che tutte le fusioni sono state completate. In tal caso, l'errore di un singolo individuo di una singola azione può causare errori nel rapporto (ad esempio, l'elaborazione ha una modalità di errore a punto singolo)?

In realtà sono necessarie 2 modifiche. Uno è la consegna al ramo principale e uno è la consegna nel ramo di manutenzione. Usa Jira per tenerne traccia come due consegne correlate.

Questo ha dei vantaggi, come ad esempio è possibile rinviare un'unione alla manutenzione desiderata, e vedere ancora ciò che è stato rinviato, ma ha un sovraccarico. Inoltre, potrebbe rendere il tuo sistema di reporting alla direzione riportare più difetti che hai realmente, a seconda di come li registri e li rapporti.