Sta spingendo i rami di caratteristiche all'origine come una buona pratica?

Question

Recentemente siamo passati da SVN a Git e siamo ancora in una fase di apprendimento quando si tratta di best practice, ecc. Sto seguendo this guide come trampolino di lancio per la gestione delle nostre filiali e pubblicazioni.

Il documento suggerisce che i rami di funzionalità sono generalmente locali per lo sviluppatore che è praticamente alla pari con quello che ho letto altrove. Tuttavia, alcuni degli ingegneri stanno lavorando su funzionalità che non saranno presenti nella prossima versione. Queste funzionalità sono da 2 a 3 iterazioni prima del ciclo di rilascio.

La preoccupazione che sento dai miei ingegneri è che sono preoccupati di mantenere così tanto codice locale. Anche con i loro processi di backup in atto, è ancora una preoccupazione. E io tendo ad essere d'accordo con le loro preoccupazioni.

Quindi la mia domanda è: è standard che i rami non previsti per le versioni più immediate vengano spinti all'origine? Ad un certo punto questi rami vengono uniti nel ramo di sviluppo e quindi cancellati dall'origine.

Ad esempio, un ingegnere sta lavorando a un pezzo di realizzazione piuttosto grande. Non vogliamo che il suo codice venga inserito nel ramo di sviluppo (sempre il nostro prossimo rilascio). Così abbiamo creato per lui un ramo di fulmine e lo abbiamo spinto all'origine. Il documento che ho collegato e altri che ho letto non rendono chiaro se si tratta di buone o cattive pratiche.

Se c'è una pratica migliore qui per favore fammi sapere o confermare la mia speculazione.

Answer 1

Dipende.

Se qualcuno sta lavorando su una funzione e desidera condividerla con altri sviluppatori, ha perfettamente senso. Ma se si tratta di una funzione su cui si sta lavorando da soli, perché spingerlo sul server se non è necessario condividerlo? Alla fine verrà incorporato in qualche altro ramo, come master o svilupparsi quando la funzione sarà completata.

Condividere i rami che devono essere condivisi, mantenere gli altri rami localmente. Non rovinare il repository principale se non ce n'è bisogno. Inoltre, altri sviluppatori dovranno pulire manualmente i loro repository di riferimenti quando i rami vengono rimossi dal repository principale, tramite l'origine di prune remote git.

Answer 2

Per caratteristiche di piccole dimensioni è opzionale. Suggerirei di spingere funzionalità di dimensioni medio-grandi su base giornaliera a scopo di backup. La tua azienda odierà sapere che il tuo sviluppatore ha perso 2 settimane di lavoro quando il suo PC è morto.