È meglio unire "spesso" o solo dopo il completamento fare una grande fusione di rami delle caratteristiche?

40

Supponiamo che siano in fase di sviluppo più rami Ae B, oltre a un ramo "bug fix" incrementale C.

Ora Cè già "finito" e unito in maestro. Ae Bsono ancora in fase di sviluppo e non verranno corretti prima che (forse) un altro ramo di correzione di bug venga unito in master.

È una buona idea unire il Cpiù presto possibile nei nuovi rami delle caratteristiche? In modo che le nuove funzionalità siano il più vicino masterpossibile? O è meglio lasciare che la nuova funzionalità venga sviluppata nel loro "mondo" solo fondendosi in master una volta terminata?

Ci saranno comunque dei conflitti, quindi è necessario dedicare del tempo per risolverli.

version-control branching merging

— paul23
fonte

2

Possibile duplicato di Qual è una buona frequenza per unire i rami delle caratteristiche in una linea principale?

— moscerino il

5

@gnat che riguarda l'unione dei rami delle caratteristiche in una linea principale, mi chiedo se fondere di nuovo la funzione principale in una funzione mentre si sta sviluppando una funzione è buono, per "risolvere i conflitti in anticipo".

— Paul23

1

@ paul23, direi che è una necessità pratica.

— Berin Loritsch,

3

Onestamente, molti dei miei problemi di versioning sono scomparsi quando ho iniziato a utilizzare la progettazione corretta sul mio codice, come isolare i moduli e creare un modello di lavoro ben definito. Se stai inciampando troppo sui problemi durante le fusioni, potresti avere un altro problema più grave in agguato da qualche parte. Un buon design è incredibilmente utile per evitare conflitti incessanti.

— T. Sar - Ripristina Monica il

2

Potresti voler unirti regolarmente dal maestro per stare vicino "abbastanza" per non rendere la fusione in un secondo momento troppo dolorosa.

— Thorbjørn Ravn Andersen,

71

Più a lungo vive un ramo, più è in grado di divergere dal ramo principale e più incasinato e più complicata sarà la fusione risultante alla fine. Dieci piccoli conflitti sono più facili da risolvere di 1 conflitto di massa e possono effettivamente impedire agli sviluppatori di duplicare o sprecare sforzi. Dato che, si dovrebbe fondersi masterin Ae Bregolarità; una volta al giorno è una raccomandazione abbastanza comune, anche se se hai molta attività sui tuoi rami potresti voler unirti più volte al giorno.

Oltre a semplificare la risoluzione dei conflitti, si menziona in particolare Cun ramo di correzione di bug. Come sviluppatore, vorrei che il mio ramo avesse tutte le ultime correzioni dei bug, per assicurarmi di non ripetere il comportamento che ha portato a un bug o di scrivere test basati su dati errati.

Ci saranno comunque dei conflitti, quindi è necessario dedicare del tempo per risolverli.

Se sai che ci saranno conflitti, potresti voler adottare una diversa strategia di ramificazione. Mantenere più modifiche agli stessi file sullo stesso ramo quando possibile e ridurre o eliminare il numero di conflitti. Rifletti le storie in modo che siano completamente indipendenti il più possibile e rielabri i rami per coprire eventualmente più storie (ramo, funzione e storia non sono sempre intercambiabili).

— mmathis
fonte

33

Unisci o rinnova, poiché la rifasatura spesso produce una cronologia di commit più pulita.

— Chrylis -on strike-

11

@chrylis: Rebasing può essere pericoloso se "rami coprono storie multiple" significa che due sviluppatori lavorano sullo stesso ramo.

— meriton - in sciopero il

9

@meriton dai documenti ufficiali: non reimpostare i commit che esistono al di fuori del tuo repository e le persone potrebbero avere un lavoro basato su di essi. Se segui questa linea guida, starai bene. In caso contrario, le persone ti odieranno e sarai disprezzato da amici e familiari. LOL

— Xtreme Biker ripristina Monica il

6

@XtremeBiker: un rebase nella cronologia delle modifiche di Git. Git funziona come la vita reale in questo senso: per cambiare la storia, hai bisogno di una cospirazione. C'è un ramo nel repository per Git stesso che viene regolarmente riformulato ed è altamente pubblico. La ragione per cui funziona è che c'è una cospirazione: tutti coloro che usano questo ramo si impegnano a riscrivere la storia in determinati momenti, quindi si accerteranno di essere in grado di far fondere tutto da quei tempi.

— Jörg W Mittag,

1

@ paul23 Prendi seriamente in considerazione di consegnare A e B a una nuova filiale condivisa prima di consegnarli al master. Se sono entrambe revisioni radicali, le vuoi insieme per un giro di prove prima di infliggere la combinazione al maestro. Se sei sicuro di poterne consegnare uno direttamente al master e quindi consegnare l'altro a una nuova filiale aggiornata. Probabilmente vuoi essere in grado di guardare il codice originale dalla seconda funzione nel caso in cui l'unione vada male o devi riprogettare qualcosa.

— Sinc

11

Supponendo che la tua intenzione sia quella di fondere nuovamente A, B in master e mantenere un'unica base di codice, non è mai una buona idea deviare dal master troppo lontano. La deviazione dal master per troppo tempo, specialmente quando correzioni di bug e altri sviluppi si fondono con il master mentre vengono sviluppati A, B, causerà sicuramente conflitti.

Vorrei prendere in considerazione strategie simili alla seguente

Chiunque sia responsabile di A, B dovrebbe guardare da vicino il padrone e fondersi in eventuali cambiamenti.
Meglio ancora, se hai compilato e testato l'automazione, assicurati che A, B si uniscano nel master e superino i test di notte.
Sulla base del tuo commento ad un'altra risposta, sembra che A, B potrebbe richiedere del tempo per svilupparsi. In questo caso, potresti anche considerare di unire anche A, B in modo che alla fine non abbia grossi problemi a fondere entrambi in master.
A un livello superiore, pensa al motivo per cui hai bisogno di 2 linee separate di lungo sviluppo. Potresti scomporre in fusioni minori? Potresti rompere in micro servizi separati?

— kenchew
fonte

5

Di solito spesso è meglio di uno massiccio.

Le richieste pull più piccole, più frequenti sono quasi sempre migliori.

Ho iniziato a utilizzare i flag di configurazione principalmente in modo da poter fare richieste pull più piccole in anticipo in modo da poter, a loro volta, unire il codice più facilmente, ma lasciare la funzione disattivata. Più piccola è la richiesta pull, più facile è rivedere il codice, anche se ci sono più richieste pull totali. La maggior parte degli umani di qualsiasi tipo non sarà in grado di fare recensioni significative di richieste di pull di massa. È troppo difficile per la propria RAM mentale comprendere tutte le possibili implicazioni di un massiccio cambio di codice.

C'è un sovraccarico aggiuntivo nella creazione di un flag di configurazione, quindi non ne vale la pena su funzionalità più piccole. Ma comunque la tua richiesta pull sarà piccola.

Ci possono essere situazioni, tuttavia, in cui la funzione deve essere rilasciata tutta in una volta. Anche allora potrebbe essere meglio fare richieste pull più piccole a un altro ramo creato a tale scopo.

La maggior parte dei miei colleghi gemono quando qualcuno crea una grande richiesta pull e, per la maggior parte, giustamente.

Si noti inoltre che a volte ho bisogno di selezionare la ciliegia in un ramo separato. Se ciò che deve essere raccolto in ciliegio può essere inserito in un unico commit, sarà più facile spostarlo in altri rami. Questo è un caso in cui in realtà avere pochi commit è meglio, ma non è esattamente il processo standard se si sceglie la ciliegia.

— Mark Rogers
fonte

1

I flag delle funzionalità possono essere costosi (450 milioni di USD in 45 minuti). Questo esempio è citato anche da Zio Bob (ma senza alcun tipo di tecnica (come ci si aspetterebbe)).

— Peter Mortensen,

1

Sì, c'è il sovraccarico di rimuoverli alla fine, anche se di solito non è così difficile. Uno potrebbe mantenerli più a lungo, ma poi la bandiera sta fornendo un uso maggiore. Sono d'accordo se fatto alla fine o senza follow-up, allora le cose possono andare male. Sebbene le cose possano andare male quando una grande richiesta pull diventa difficile da rivedere. D'altra parte, alcune persone potrebbero non essere in grado di aggiungere qualcosa come un flag di configurazione all'app che stanno funzionando. In genere aiuta con UAT e il lancio di una funzione.

— Mark Rogers,

3

In Refactoring di Martin Fowler, il consiglio che dà è di non lasciare mai una branca ramificata dal padrone per più di un giorno. IIRC, dovresti apportare una piccola modifica, testare per accertarti di non aver rotto nulla, quindi ricollegarlo.

— JohnnyApplesauce
fonte

2

Bene Ae Btenere importanti nuove radicali modifiche a come funziona l'applicazione, non vengono "fatte" entro un mese. Tuttavia sono anche inutili prima di aver finito ...

— Paul23,

8

Potrebbero non essere inutili prima di aver finito: forniscono valore essendo un passo verso il risultato completo e riducendo il lavoro richiesto in futuro. Utilizzando tecniche come le funzioni di commutazione, ramo per astrazione o semplicemente eseguendo l'ultima parte dell'interfaccia utente, dovrebbe essere possibile unire in modo sicuro il lavoro incompleto al master.

— bdsl,

1

ecco perché riequilibrare il locale in cima a qualsiasi cambiamento nel ramo principale è utile per uno sviluppo a più lungo termine. Mantiene il tuo lavoro come se fosse appena stato ramificato dall'ultimo

— NKCampbell il

2

Un'altra opzione per le modifiche di lunga durata che possono essere finite ma non pronte per l'uso è quella di metterle dietro un flag di funzionalità in modo che possano essere unite al master ma non hanno il rischio di rompere qualcosa. Quindi, quando sono pronti per essere utilizzati, è possibile rimuovere il flag delle funzionalità.

— Qwertie
fonte

1

Feature flags = codice zombie (fino a quando non viene resuscitato)?

— Peter Mortensen,

@PeterMortensen Bene, devi mirare a rimuovere le bandiere il più presto possibile, ma potrebbe funzionare in determinate situazioni

— Qwertie

3

@PeterMortensen non se la bandiera è attiva per almeno una persona

— Ian