Git workflow e subtrees

2

Sto lavorando a una squadra che è distribuita geograficamente tra l'Australia e le Filippine. Fino a poco tempo fa, abbiamo utilizzato un singolo server SVN per mantenere il nostro codice, con il server contenente alcuni repository (chiamiamoli Client, API e Common), con codice comune condiviso tra client e API tramite gli elementi esterni SVN. Utilizziamo TeamCity per CI e Octopus Deploy per le distribuzioni automatizzate; i rilasci di funzionalità vengono in genere eseguiti ogni 2-3 mesi, con rilasci di manutenzione come e quando necessario.

Ora ci stiamo spostando su BitBucket come VCS e abbiamo alcuni problemi con il flusso di lavoro generale. In primo luogo, per questioni di controllo esterno, dobbiamo impedire a tutti gli sviluppatori di essere in grado di eseguire il commit nei repository master, quindi abbiamo creato repository di sviluppo client, api-sviluppo e sviluppo comune e concesso solo ai leader del team le autorizzazioni di scrittura sul master repository e tutti scrivono le autorizzazioni sui repository di sviluppo. Fin qui, tutto bene.

Il problema principale che stiamo avendo riguarda la condivisione del codice nel repository comune. Quando uno sviluppatore inizia a lavorare su una nuova funzionalità, deve creare rami su ciascuno dei tre repository e quindi creare una sottostruttura sullo sviluppo client e sullo sviluppo API che si ricollega allo sviluppo comune, utilizzando i rami appena creati. Ma poi quando spingono indietro il loro codice e qualcun altro tenta di usare quel codice, la sottostruttura è scomparsa e ora è solo una normale cartella nel codice sorgente.

Penso che la nostra strategia di flusso di lavoro migliore sarebbe una variante di gitflow, dove -master è la copia "pristine" che solo i lead del team possono modificare accettando le richieste pull e tutte le altre funzionalità di gitflow implementate nello sviluppo forchette. Tuttavia, i problemi dei sottoalberi ci rallentano davvero.

In che modo i sottotitoli possono essere utilizzati efficacemente per condividere il codice tra repository, senza doverli eliminare e ricreare ogni volta che unisci il codice?

    
posta David Keaveny 20.04.2017 - 05:58
fonte

1 risposta

1

Suggerisco di utilizzare i sottomoduli anziché i sottoalberi in quanto comune è un componente sia del server che del client. Con i sottomoduli, ogni ramo del repository padre (nel tuo caso cliente / server) può puntare a un commit del repository figlio (nel tuo caso comune).

Per maggiori dettagli, fai riferimento alla documentazione del Git Submodule

    
risposta data 24.04.2017 - 21:49
fonte

Leggi altre domande sui tag