git-flow: Come prevenire alcune modifiche apportate al ramo di release dalla fusione di nuovo allo sviluppo

La domanda è su alcuni casi limite git-flow metodologiagit-flow: Come prevenire alcune modifiche apportate al ramo di release dalla fusione di nuovo allo sviluppo

ho qualche tipo di storia tipica git-flow in questo modo:

 o---o---o---o [release-3.5.0] 
    /
----o---o---o---o---o [development]

Git-flow ci ha detto di fondere release-3.5.0 ramo in sviluppo quindi rilasciare è pronto. Quindi, alla fine avremo le modifiche ALL, apportate al ramo di rilascio nel ramo di sviluppo.

 o---o---o---o 
    /   \ 
----o---o---o---o---o [development]

Ora immaginate, abbiamo un commit 'X' sul ramo di release ciò che FACCIAMO NON vogliono al ramo di sviluppo, ad esempio, è una sorta di hack/hotfix oppure che è già fissato in fase di sviluppo in modo più corretto (es. con commit Y)

 o---X---o---o [release-3.5.0] 
    /
----o---o---o---Y---o [development]

Quindi, la domanda principale è come affrontare tali situazioni? Come impedire che questo commit (o commit) torni nello sviluppo?

fonte

2013-06-24 Olegas

Possibile duplicato di [git - commit specifici per saltare quando si fondono] (http : // StackOverflow.it/questions/727994/git-skipping-specific-commits-when-merging) – Lu55

Mentre le risposte raccomandare rebase e/o fondere/ripristinare/zucca funzionerà, io personalmente penso che la risposta migliore sarebbe questo:

git checkout development 
git merge --no-commit release-3.5.0 
# make whatever changes you need to fixup the "hack" and/or clean up any conflicts 
git commit

fonte

2013-06-24 15:00:54 twalberg

'--no-commit' non genera 'informazioni di fusione'. Il ramo di rilascio non verrà mostrato nella cronologia come unito, non verrà trattato come unito da comando come 'git branch --merged'. Quindi, si può accidentalmente unirlo per errore. – Olegas

@Olegas Mentre il commento è tecnicamente corretto, seguendo il flusso di lavoro completo sopra * creerà "informazioni di fusione" (presupponendo che si intenda una combinazione del messaggio di commit formattato in fusione e/o dei puntatori padre che creano un'unione nel history DAG), ma è il 'git commit' finale che crea quelli. 'Git merge --no-commit' imposta semplicemente le cose in modo che vengano creati i metadati appropriati. Se provi 'git branch --merged' prima dell'ultimo' git commit', esso mostrerà correttamente che il ramo non è ancora stato unito, perché l'unione non è stata commessa ... – twalberg

sì, hai ragione. Dopo il commit tutto va bene, incluse le informazioni di fusione, ho sbagliato. – Olegas

sono disponibili diverse opzioni:

1) Utilizzare git rebase -i

In questa modalità è possibile rebase la tua ramo di release sul ramo di sviluppo ed escludere il X commesso.

Avviso In questo caso si confondono i repository clonati esistenti.

2) utilizzare git cherry-pick

In questo modo si avrà la possibilità di scegliere commette uno per uno.

3) utilizzare git rebase -i su un ramo separato e fonderlo in seguito, come specificato in questa risposta: Is it possible to exclude specific commits when doing a git merge?

fonte

2013-06-24 10:04:46 StKiller

'rebase' non è adatto perche 'l'avviso che hai notato,' cherry-pick' è accettabile ma troppo complicato causa' ramo di rilascio che ho anch'io molti si impegnano (ma possono essere automatizzati in qualche modo). – Olegas

cherry-pick consente effettivamente il prelievo di un intervallo di commit (http://stackoverflow.com/a/1994491/696792), ma questo include anche alcuni problemi (specificati nella risposta collegata) – StKiller

Aggiornamento della risposta con la terza via. – StKiller

In tali scenari si sempre desidera unire pienamente le() -come rami di rilascio. Quindi assicurati che non manchi nulla.

Ma durante l'unione è possibile modificare liberamente il contenuto, anche per eliminare o ripristinare alcune modifiche. Per il tuo caso di esempio, unisci il ramo, ripristina il commit che non ti piace e schiaccia quello ripristinato nel commit di unione. Ovviamente prendi nota nel messaggio di unione di commit di quell'azione.

Se la correzione è già su devel, l'unione verrà ignorata o risolverà il conflitto selezionando la versione di sviluppo.

Il punto è che vuoi che la cronologia mostri la tua seconda figura e lo stato che ha più senso.

fonte

2013-06-24 10:14:30

git-flow: Come prevenire alcune modifiche apportate al ramo di release dalla fusione di nuovo allo sviluppo

risposta

Problemi correlati