Quando si sviluppa su un ramo di lunga data (qui definito come vivere più a lungo di una versione), qual è la pratica più accettata per mantenere il ramo corrente con la sua origine mantenendo la cronologia relativamente pulita prima di fondersi?
Ad esempio, considera il ramo di origine ( m ) e un ramo (argomento) ( t ) con il seguente grafico cronologico:
A[1]--------F[2]--H[3]--J[4] (m)
\ \ \
B----C-D-E--G-----I-----K (t)
[1] - Release 1.0
[2] - Release 2.0
[3] - Hotfix 2.1
[4] - Hotfix 2.2
Nel ramo t Mi sono unito periodicamente dal master ( m ) per mantenere aggiornato il mio topic topic, ma ci sono molti piccoli commit tra B e K che mi piacerebbe schiacciare con un rebase.
Sono preoccupato se schiaccio quei commit che cambierò l'hash dei commit uniti dal master e creerò problemi per gli altri quando unirò il mio branch in master per la Release 3.0.
Se I rebase -i il ramo dell'argomento, mi aspetto che il grafico assomigli a questo:
A---------F---H---J (m)
\
B-----------------K (t)
dove K contiene tutti i commit schiacciati tra B e K incluse le modifiche unite dal master ( F e H ). Se poi unisco t di nuovo al master m Mi chiedo se ci siano probabilmente conflitti da F e H . Il grafico dovrebbe apparire così:
A---------F---H---J---L (m)
\ /
B-----------------K (t)
t ora può essere eliminato perché non è più utilizzato. Mi piacerebbe mantenere la cronologia di dove t è stato derivato, quindi basare B su J perderebbe quell'informazione e probabilmente risolverebbe il mio problema ma il grafico sarebbe simile a:
A---------F---H---J---K' (m)
Questa è una preoccupazione valida? Qual è la pratica comunemente accettata per mantenere la propria diramazione caratteristica con la sua origine mantenendo una cronologia relativamente pulita?
Nota: l'esempio qui è semplificato, ci sono in realtà centinaia di commit dal punto di diramazione a HEAD sul ramo dell'argomento - oltre 300 - molti dei quali potrebbero essere schiacciati dall'esistenza