Strategia di repository per più componenti interconnesse con piccole differenze

Question

Strategia di repository per più componenti interconnesse con piccole differenze

#1 da (2 voti)

1

Nel mio lavoro abbiamo più prodotti .. prodotto A, prodotto B, ... questi prodotti fanno riferimento a più componenti. componenteA, componenteB .. ci sono anche componenti condivisi sharedA, sharedB ... etc .. che sono condivisi da più componenti, più prodotti o da un prodotto e un componente.

Al momento stiamo spostando tutte queste cose per separare i repository Git, tuttavia, abbiamo difficoltà a trovare un modo per configurare i repository in modo che tutto rimanga gestibile.

Abbiamo due problemi che rendono difficile l'impostazione dei repository.

Ci sono molte dipendenze. Quando voglio lavorare su ProductA ho bisogno di avere il codice sorgente per ProductA, componentA, componentB e sharedComponentC sul mio computer, dal momento che potrei cambiare il codice in tutti loro. Per ProductB ho bisogno di componentA, sharedComponentC e ... questo rende difficile scegliere cosa memorizzare in quale repository.
Dire componentA è una libreria di interfaccia, questa libreria di interfaccia è utilizzata da ProductA e ProductB. Per ProductA ha bisogno di funzionare normalmente, ma in ProductB è necessario mostrare un pulsante in più. Abbiamo molte di queste piccole differenze nei componenti dovremmo creare un ramo per prodotto e talvolta integrare i rami per assicurarci che abbiano le stesse nuove funzionalità? Forse svilupparsi su un ramo "generale" e spingere i cambiamenti in ogni ramo "piccola differenza"? È brutto avere un sacco di rami attivi in un progetto?

Esistono regole empiriche che aiutano a decidere come suddividere il software su più repository? Quali sono i buoni modi per lavorare su un software che si trova in più repository o strumenti che aiutano in questo senso? Qual è l'impostazione corretta del repository per i componenti con molte piccole differenze? Alla fine queste sono tutte la stessa domanda. Qual è una buona strategia di repository per più componenti interconnesse con piccole differenze?

Altre informazioni che potrebbero essere d'aiuto. Sviluppiamo esclusivamente su Windows, il 99% del codice che scriviamo è C #, l'altro 1% è C ++ / CLI. Tutti i nostri sviluppatori hanno accesso a Visual Studio 2013 Pro. Siamo disposti ad acquistare software per aiutarci con questo problema, ma siamo una piccola azienda, quindi non abbiamo budget infiniti:).

Naturalmente una parte dei problemi che stiamo avendo sono dovuti a (cattive) decisioni di progettazione in passato. (Nessuna decisione di progettazione può tutelare completamente contro lo sviluppo futuro del tuo software / azienda;)) Stiamo lavorando per cambiarlo. Ma per il momento vorremmo decidere una strategia di repository moderna che renda le cose un po 'più gestibili.

git version-control c# svn repository

posta Roy T. 04.02.2015 - 09:45

fonte

1 risposta

Leggi altre domande sui tag git version-control c# svn repository

supporto torrent nel browser Differenza tra gli attori nel sistema esistente (non automatizzato) e il nuovo (automatizzato) [chiuso]

score 2 · Accepted Answer

Con git puoi usare git submodule .

ProdottoA può avere commit_id specifici (che possono essere un ramo) di alcuni sottomoduli (ad esempio ComponentA , ComponentB , SharedComponentC ).

Per aggiungere un componente a ProductA, dalla directory ProductA sul tuo computer di sviluppo fai:

C:\projects\ProductA.git\> git submodule add --branch master --name ComponentA http://reposerver.ourcompany.com/ComponentA components/ComponentA
C:\projects\ProductA.git\> git submodule add --branch master --name ComponentB http://reposerver.ourcompany.com/ComponentB components/ComponentB
C:\projects\ProductA.git\> git submodule add --branch ProjectA --name sharedComponentC http://reposerver.ourcompany.com/ComponentC components/sharedComponentC

Altri sviluppatori possono usare:

C:\projects\ProductA.git\> git submodule init
C:\projects\ProductA.git\> git submodule update

per ricevere le versioni corrette dei sottomoduli nella loro directory di lavoro.

Quando apporti alcune modifiche a un sottomodulo, commetti le modifiche del sottomodulo e impegni la nuova versione del sottomodulo nel progetto, cioè:

C:\projects\ProductA.git\components\sharedComponentC\> git add ...
C:\projects\ProductA.git\components\sharedComponentC\> git commit
C:\projects\ProductA.git\components\sharedComponentC\> cd ..\..
C:\projects\ProductA.git\> git add components/sharedComponent
C:\projects\ProductA.git\> git commit

Commento

Ho usato la sintassi della riga di comando per spiegare come usare git; sei libero di utilizzare qualsiasi strumento grafico o plugin di Visual Studio che ti piaccia.
Ho controllato la sintassi e i parametri sotto Linux e tradotto gli esempi nel prompt dei comandi di Windows, quindi potrebbero esserci alcuni errori (ad esempio barre anziché trattini); fai riferimento al manuale di riferimento di git per la sintassi esatta.
La directory del progetto ( C:\projects\ProductA.git ), il nome del ramo ( ComponentA ), il percorso del repository ( http://reposerver.ourcompany.com/ComponentA ) e la directory del sottomodulo ( components/ComponentA ) possono variare in modo indipendente.