Il nostro piccolo negozio di software ha recentemente migrato da Subversion a Git, in quanto i programmatori hanno trovato Git migliore. La migrazione non è stata indolore, stiamo riscontrando problemi con la funzione dei sottomoduli. La mia lamentela principale è che una volta che un repository contiene dei sottomoduli, non puoi semplicemente clonarlo e aspettarti che le cose funzionino. Devi fare un ulteriore passaggio per avviare e scaricare i sottomoduli. Tiri successivi dovrebbero update the submodules automatically, quindi va bene. Ma quando aggiungo un nuovo sottomodulo, spingo il commit e la gente tira, non ottengono automaticamente il nuovo sottomodulo, devono farlo di nuovo a mano git submodule update.Come rendere i sottomoduli Git più facili per i non programmatori?
Questo è stupido, poiché le persone non possono semplicemente estrarre un repository con i sottomoduli e aspettarsi che si costruisca. Questa comprensione è corretta? I programmatori possono semplicemente scrivere una sceneggiatura o un alias per aggiornare i sottomoduli dopo aver ricevuto nuovi commit, ma per i nostri sottomodatori non programmatori è un problema. Mi piacerebbe trovare una soluzione che faccia funzionare il repository subito dopo la clonazione/estrazione, indipendentemente dal client Git utilizzato.
Quali sono le mie opzioni?
Si consiglia di utilizzare il comando 'git clone --recursive' per il clone iniziale, che si occuperà di parte della domanda. –
Grazie, non sapevo di '--recursive'. Ma i nostri non programmatori usano un client GUI (attualmente GitBox), motivo per cui sto cercando una soluzione diversa. Sarebbe perfetto avere un supporto di prima classe per i sottomoduli nella GUI, ma non ho intenzione di trattenere il respiro. – zoul
Sei sicuro che il percorso del sottomodulo sia l'approccio giusto? I sottomoduli dovrebbero essere moduli autonomi, quindi se le cose si rompono senza di loro, allora non è propriamente autonoma. – bluesman