Git and merge commit

Il tuo flusso di lavoro sembra simile a "Git Flow" , tranne per il fatto che avvii la funzione rami da master , mentre il Git Flow consiglia la derivazione da dev .

L'idea è che dev rifletta da vicino lo stato di sviluppo corrente. I branch di feature dovrebbero essere di breve durata (al massimo un paio di giorni di sviluppo). Pertanto, quando una funzione è derivata da dev e reimmessa in dev al giorno dopo, ci saranno pochissimi conflitti. Il ramo dev verrebbe utilizzato per l'integrazione continua.

Git Flow suggerisce quindi di ramificare un ramo di rilascio (il staging ) dal ramo dev con più nuove funzionalità per il controllo qualità e la preparazione del rilascio. Al momento del rilascio, il codice viene unito in master in modo che master contenga solo versioni pubblicate completamente testate.

Se dovessimo escludere nuove funzioni da master (ovvero l'ultima versione pubblicata), ignoreremmo tutte le altre funzionalità che sono state unite in dev nel frattempo. Anche se il diff tra dev^ e dev potrebbe essere piuttosto pulito, ci sarebbero grandi differenze nella storia:

             Am                                    B..Zm
  master ----x------------------------------------x
            / \                  \               /
 staging --x---|------------------|-------------x B..Zs
          /As  |         B  C..Y  |          Z /
     dev x-----|---------x--x--x--|-----------x
         A      \       /  /  /   |          /
featureB         x--x--x  .....   |         |
                 B1 B2 B3         |         |
  ...                             |         |
                                   \       /
featureZ                            x--x--x
                                    Z1 Z2 Z3

Alla fusione B in dev (A) da featureB (A As Am B1 B2 B3) , l'unione è piuttosto pulita. Quindi aggiungiamo un paio di altre caratteristiche C a Y in dev . Successivamente, la cronologia di dev ha l'aspetto di A As Am B1 B2 B3 C1 C2 C3 ... Y1 Y2 Y3 . Sembra ancora ragionevole. Infine, abbiamo il ramo featureZ con la cronologia A As Am Z1 Z2 Z3 - nota che Am è il commit dell'antenato comune più vicino di dev e featureZ .

Il risultato è che all'unione Z , non testiamo solo l'effetto del commit Z1 Z2 Z3 , ma l'effetto di combinare tutte le caratteristiche B1 B2 B3 C1 C2 ... Y2 Y3 Z1 Z2 Z3 .

L'impatto di questo problema è ridotto dai rilasci frequenti, quindi la differenza tra dev e master non è così pronunciata. Tuttavia, questo rende solo il problema più piccolo e non lo risolve. TeamCity sembra rendersi conto che in realtà sta testando tutte le modifiche apportate dall'ultima fusione con il master, sebbene queste non siano ovvie nella cronologia del ramo (poiché dev contiene solo commit merge).

Ho ricreato l'esempio di ramificazione sopra come un vero repository git, che è disponibile come latk / Git-Branching-Madness su GitHub . Puoi guardare il grafico delle filiali online oppure clonare il repository e controllarlo tu stesso, ad esempio:

                          # tip: use "git log" with "--pretty=oneline"
$ git log featureZ        # history of featureZ
$ git log dev^            # complete history of dev before featureZ merge
$ git log dev^..dev       # what commits were added during the featureZ merge
$ git log master --graph  # display complete branching history

L'unione di più volte non dovrebbe essere un problema, e questo è in realtà un modo normale di lavorare con Git.

Il tuo team ha accettato di avere un flusso di lavoro specifico. Per le piccole correzioni, ciò potrebbe comportare un sovraccarico, ad esempio, per l'unione diretta su master . Ma va bene, almeno hai un processo per eseguire l'integrazione continua.

Ora, non conosco TeamCity, ma forse dovresti concentrarti sul perché ha oltre 100 cambiamenti in sospeso quando il diff è veramente piccolo.

Un'opzione è frequentemente git fetch e git merge / git rebase master durante lo sviluppo e qa per tenere il passo con le modifiche e risolvere i conflitti mentre accadono. Preferisco git rebase che riproduce le tue modifiche in cima al master più recente