Come mantenere i rami git di lunga durata

Question

I rami di Git dovrebbero idealmente durare per poco tempo, probabilmente per 1-2 giorni. Quindi viene unito in alcune linee principali.

Ma in alcuni casi, dove lavoriamo su funzionalità molto grandi, manteniamo filiali. E quando 2 o 3 persone lavorano su queste funzionalità molto grandi in aree esclusive di codice, diventa piuttosto difficile mantenerle.

Tra hot fix che vanno al ramo stabile, dobbiamo mantenere questi 2-3 rami grandi in sincronia con il ramo stabile. Quindi finiamo col fare questo, abbastanza spesso.

(in feature-branch1) $ git merge stable 
(in feature-branch2) $ git merge stable 
(in feature-branch3) $ git merge stable 

C'è un modo giusto per mantenere questi rami di lunga durata in git? Facendo quanto sopra, la storia git è un po 'disordinata. Questi rami di funzionalità vengono in genere trasferiti su un telecomando, il che significa che non è possibile vedere rebase come opzione. Cos'altro posso fare?

Answer 1

L'unione nel ramo stabile di tanto in tanto è in realtà la cosa più semplice e migliore che si possa fare per mantenere aggiornato il proprio ramo delle funzioni. Non consiglierei la rebasazione perché potrebbero esserci più persone che lavorano alla funzione nello stesso momento e dovrebbero reimpostare i loro rami locali molto ogni volta che c'è stata una spinta forzata. Anche se una sola persona lavora sul ramo della funzione, la fusione è migliore perché mostra chiaramente il punto nella storia in cui hai apportato correzioni dal ramo stabile.

Sì, la cronologia può sembrare un po 'disordinata una volta che il ramo delle funzioni è stato reso stabile. Ma fintanto che stai evitando il caos delle micro-fusioni quotidiane dai tuoi git pull (usa invece git pull --rebase), sarai in grado di apprezzare le fusioni significative e reali.

Se si in realtà si desidera evitare l'unione di nuove funzionalità da stabile nel ramo di funzionalità, ma si desiderano solo correzioni di errori, è possibile selezionare i bugfix nel ramo di funzionalità. Tuttavia questo può essere molto lavoro perché richiede di essere sempre al top di tutto ciò che sta accadendo in stable. Utilizzare git cherry per aiutarvi:

# commits from "stable" that are not present in 
# the current branch will be prefixed with "+" 
git cherry HEAD stable 

Answer 2

Il rifondazione è possibile se il team è abbastanza piccolo e comprende utenti Git ragionevolmente esperti.

Ciò che si può fare è, ad esempio, essere d'accordo sul fatto che il ramo delle caratteristiche verrà ridefinito su stabile ogni notte. Oppure puoi inviare una e-mail quando rebase il branch delle funzionalità a stable.

Tutto dovrebbe andare bene, ma nel caso in cui si dimentica di sincronizzazione con il ramo di caratteristica ricalcolato, dici hai commesso C in cima alla vecchia funzione ramo oldFB, che è stato ricalcolato in oldFB':

S1 - oldFB - C <-- feature-branch 
    \ 
    S2 - oldFB' - D <-- origin/feature-branch 

E 'ancora possibile rebase vostro commit (s) C eseguendo:

git checkout feature-branch 
git rebase --onto origin/feature-branch oldFB C 

noti che dovrete trovare manualmente il commit chiamato oldFB nello schema sopra.

Answer 3

L'opzione migliore è quello di fondere solo i rami piccoli bugfix/funzione richiesta nelle vostre longevi funzionalità rami. In questo modo ottieni solo ciò di cui hai bisogno. Nota che se lasci che questi rami vivano abbastanza a lungo, alla fine potrebbero diventare abbastanza fuori sincrono dal master.Di tanto in tanto, potresti voler creare un ramo temporaneo fuori dal tuo branch di funzionalità a lungo termine e unire master in esso solo per fare controlli di integrità - vedi se ci sono conflitti, vedi se i cambiamenti in master interrompono la funzione, e così sopra.

Il prossimo passo sarebbe quello di unire periodicamente il master nei rami delle funzionalità longevi. Questo è abbastanza sicuro, ma può anche unire molte modifiche che non ti interessano e complicare le cose.

Vorrei non consigliare di rebasare periodicamente sul master. Rende difficile per tutti rimanere sincronizzati, inoltre rende molto più difficile mantenere una storia complessa (unione) sui rami delle funzionalità e rende la risoluzione dei conflitti più dolorosa.