Sto ripulendo il nostro repository git e c'è un ramo di funzionalità che contiene un prototipo di una caratteristica interessante che la direzione ha deciso di non includere presto nel prodotto.
Che cosa fai in una situazione del genere con il ramo delle funzionalità? È una situazione in cui la funzionalità di Github Gist potrebbe essere utile?
Probabilmente non dovresti nuotare completamente questo lavoro dalla cronologia e dovrebbe essere chiaro per chiunque altro di cosa tratta questo prototipo e cosa fare al riguardo. Pertanto, devi conservare e documentarlo .
Ad esempio, se hai una guida per sviluppatori, un bug tracker, un elenco di cose da fare, ... aggiungi una voce per quel ramo per mantenere un riferimento sulla funzione. Successivamente, qualcuno può controllare le funzionalità non raggruppate e decidere nuovamente se vale la pena integrarle. In alternativa, o in aggiunta, usa ...
Può avere senso preferire avere rami solo per lavori attivamente sviluppati e usare tag per alberi che non cambieranno in qualsiasi momento. Quindi se sostituisci il tuo ramo con un tag annotato, tu (1) rimuovi un ramo e (2) hai l'opportunità di documentarlo:
git checkout branch
git tag -a unmerged/featureA
# Write in editor
git checkout master
git branch -D branch
Idealmente, scrivi una serie di test automatici per questa funzione, quindi esegui il commit su Master senza alcun modo per accedervi esternamente (quindi nessuna interfaccia utente e nessuna API pubblica per esso) e quindi l'integrazione continua garantirà il codice per quella funzionalità rimane funzionale fino a quando non sei finalmente in grado di esporlo. Nessun ramo penzolante di cui preoccuparsi.
Ovviamente, questa è solo una buona idea se è estremamente probabile che la funzione venga utilizzata un giorno, è estremamente probabile che i requisiti per essa non cambino drasticamente prima che ciò accada, ed è possibile scrivere significativi test di unità / integrazione senza esponendo l'accesso ad esso. Se qualcuno di questi non si applica, allora probabilmente dovrai o vorresti riscrivere molto del codice quando la funzione diventa desiderabile. In questo caso, il ramo corrente sarà utile solo se pensi semplicemente di guardarlo o se ne copi in modo selettivo alcuni pezzi quando sarà il momento di riscriverlo, nel qual caso lascerei quel ramo così com'è (o lo convertirò in un tag) per riferimento futuro senza alcun tentativo di mantenerlo integrabile nel tempo.
Se sei assolutamente certo che non ne avrai più bisogno e che dovrebbe andare via, quindi eliminare tutti i tag e i rami che puntano ad esso, e git finirà per raccogliere i commit "loose".
Se vuoi mantenerlo ma non avere un ramo libero (che indica il lavoro di sviluppo), converti il ramo in un tag.
Si può anche semplicemente biforcare o clonare il repository in una posizione di archiviazione dove le persone possono andare se per qualsiasi ragione hanno bisogno della vecchia funzionalità. È quindi possibile eliminare il repository funzionante in base a ciò che è effettivamente necessario. L'ho usato per una conversione CVS- > Subversion- > Git con un sacco di vecchi artefatti binari di cui non avevamo bisogno. Avere il pieno repository convertito nel back storage ci ha permesso di tagliare in modo sicuro il futuro repository per rimuovere gli artefatti binari e spostare alcuni file nelle loro posizioni future conservando la cronologia.
Leggi altre domande sui tag git version-control branching