git: repository multipli ma ancora "raggruppati"

2

Ho un'applicazione piuttosto semplice che consiste in un frontend angolare e un'API REST fatta in C # Per il frontend utilizzo WebStorm e per il back-end Visual Studio. Ora abbiamo bisogno di introdurre un nuovo controllo di versione e si è deciso di utilizzare Team Services (Git).

Non ci sono codici o risorse condivisi tra frontend e backend, ma sono accoppiati logicamente perché il frontend ha bisogno del backend e il backend è solo (e sarà sempre e solo) utilizzato da questo particolare frontend.

Sono abbastanza nuovo per Git ma so (un po ') cosa sono i sottomoduli, sottostruttura ecc.

Il mio pensiero iniziale era: Chiaramente, due repository sono la strada da percorrere, dal momento che posso pubblicare frontend / backend separatamente su server diversi, purché il backend esista da qualche parte a cui il frontend abbia accesso, tutti saranno felici. E:

  • Webstorm e Visual Studio non interferiscono tra loro e "rubano" i commit (che personalmente trovo noiosi).
  • O mostra i file che non appartengono al progetto. Ad esempio vedrei ogni file di backend quando apro il mio frontend in webstorm poiché si trovano nello stesso repository. O mi sbaglio?

D'altra parte dovrei assicurarmi che Frontend e Backend siano sempre compatibili. Quale penso non sia così difficile. Ma quei due repository sarebbero completamente separati in git e non ci sarebbe alcuna connessione tra i due.

Per quanto ne so non è possibile dire a git o webstorm / visual studio di usare solo una sottodirectory specifica, giusto?

Quindi, la mia domanda sarebbe. Cosa consiglieresti in questo caso?

  • due repository
  • un repository con solo sottodirectory
  • un repository con sottoalberi (e un repository principale vuoto?)
  • qualcosa di diverso

Grazie in anticipo

    
posta Arikael 29.05.2017 - 16:23
fonte

1 risposta

3

Il più grande problema a cui penso per progetti come questo è, 'Come posso mantenere il front-end e l'API in-sync l'uno con l'altro?' Non vuoi che il tuo front-end chieda cose che non esistono o che sono state deprecate dalla tua API.

Il modo più semplice per risolvere questo problema è quello di avere un repository, in cui i cambiamenti nell'API e nel front-end sono tutti nello stesso commit / PR.

Questo cade a pezzi in molti posti però. Può essere più difficile se desideri sostituire la tua API o il front-end in un secondo momento. Inoltre, si può finire per perdere un sacco di tempo quando si esegue la distribuzione se si dispone di un passo di costruzione lungo o di una suite di test di grandi dimensioni.

C'è un altro post che supera un molti pro e contro, ma penso che questo si riduca davvero alle dimensioni del team e al modo in cui si pianifica di fare distribuzioni. Se è una piccola squadra, anche fino a 4 persone, probabilmente stai bene con un repo. Se hai un team numeroso e una versione dedicata e così via, la gestione di un repository può sfuggire di mano.

Ancora una volta, consiglierei di guardare l'altro post in quanto la domanda e la risposta forniscono molte buone considerazioni.

Quando separare un progetto in più sottoprogetti

    
risposta data 29.05.2017 - 23:19
fonte

Leggi altre domande sui tag