Flusso di lavoro Git - avvisare un principiante

5

Sto iniziando a lavorare con git per la prima volta, e sto cercando di creare un flusso di lavoro che funzioni per me, quindi ho pensato di venire a chiedere in giro.

In questo momento, sono in un paio di progetti in cui sono l'unico programmatore e, in effetti, l'unico pusher all'origine.

Sto lavorando in questo modo, dove c è un commit, p è un push e m è un unione:

              /feature2-c-c-c-c-m-c-c-c-c
             /                 /     \
master-----------------------m-p------m-p
        \                  /           \  
         \-feature1-c-c-c-c-c-c-c-c-c-c-m-c-c

Ora ho capito che il rebasing sarebbe più "corretto" di quei merge master che faccio nei rami delle funzionalità, o almeno è così che sembra ... ma non sono sicuro di farlo destra. Quello che ho capito ora è che unendo il master nei miei altri rami, mi pasticcio con la cronologia del mio ramo, e aggiungo tutte le funzioni indipendenti "che ci impegnano.

Forse dovrei ramificarmi di più, tramite la sottoattività, aggiungendo un terzo livello come questo:

                 ....................\
master---------------------------m-p--m-p-....
        \                       /         \
         \-feature1------------m-----------m.....
            \                 /             \  
             \-feature11-c-c-c          feature12-c-c-c..

Questo lascia irrisolto il fatto che a volte una funzionalità è più grande di quello che dovrebbe essere un ramo.

Questi sono i miei pensieri sull'argomento fino ad ora, quindi sono molto aperto a suggerimenti su quale sia il miglior flusso di lavoro git nei team di una o due persone.

Spero che i diagrammi siano facili da seguire.

    
posta Lacrymology 17.06.2011 - 00:39
fonte

2 risposte

4

TL; DR : il tuo flusso di lavoro git non è realmente il problema. Il problema è che hai bisogno di più, piccole iterazioni sulle funzionalità che hai inserito nei tuoi rami topici. Ciò ridurrà il dolore di mantenere questi rami attuali aggiornati e di integrarli nell'upstream.

Sicuramente vuoi mantenere aggiornati i rami non divisi con i cambiamenti nel loro upstream e il rebasing è generalmente il modo corretto per farlo.

Il tuo commento che "a volte una funzionalità è più grande di quello che dovrebbe essere un ramo" mi porta a credere che tu abbia rami di attualità di lunga data che trovi difficile integrare con il tuo ramo di integrazione. Questo, secondo la mia esperienza, è l'effettiva radice del tuo dolore.

Immagina se i tuoi rami di attualità sono durati alcune ore e poi sono stati uniti al ramo di integrazione. È probabile che questi rami effimeri siano banali da tenere aggiornati e banali per ricongiungersi al ramo di integrazione. D'altra parte, immagina un ramo di attualità di lunga data che si estende su più versioni del software senza integrazione. Probabilmente sarebbe abbastanza difficile da integrare. Questo dovrebbe portarti a concludere che i rami di attualità di breve durata che sono frequentemente rebasati rispetto al master sono più facili da usare.

La domanda, quindi, diventa "perché le caratteristiche dovrebbero essere più grandi di quello che dovrebbe essere un ramo?" Questo è probabilmente perché stai cercando di fare troppo in una volta. Il modo migliore per mantenere i rami di attualità di breve durata e rendere l'integrazione indolore è lavorare in modo iterativo in cui la caratteristica minima negoziabile è spietatamente abbreviata fino al suo essenziale e ulteriori lavori su tale funzione sono aggiunti in incrementi separati.

    
risposta data 17.06.2011 - 01:07
fonte
-4

Se sei l'unico sviluppatore, perché renderlo così complicato? Avere un unico ramo master, commettere modifiche localmente e premere solo quando si è sicuri che il codice funzioni. Se cerchi di implementare una funzione e non funziona, ripristina il commit prima di provare a implementarla.

    
risposta data 17.06.2011 - 03:25
fonte

Leggi altre domande sui tag