Come strutturare al meglio Git per il nostro team [chiuso]

Naviga le tue risposte
3

Stiamo iniziando a sviluppare molti piccoli progetti web nella nostra azienda, dove per lo più avranno una risorsa condivisa con alcuni pezzi di codice (SDK, utilità ed ecc ...)

Il nostro team è piccolo (~ 5), ma è in crescita e si prevede che cresca x2-x3 in diversi mesi.

Stiamo discutendo su quale sarebbe il modo giusto per costruire il nostro controllo del codice sorgente e abbiamo trovato 2 idee principali:

  1. Inserisci tutto il codice in un repository che verrà sincronizzato con Github. Tutti avrà la copia di tutti i progetti e avrà la condivisione cartella delle risorse pure - così sarà in grado di tirare / spingere il condiviso codice e il codice del progetto con una sola azione. Inoltre, ci sarà non è necessario seguire più repository. Dall'altro lato, questo potrebbe creare confusione ed errori - come tutto il codice tirato / spinto anche se si lavora solo su un progetto.

  2. Metti ciascun progetto nel proprio repository e inserisci le risorse condivise progetto nel proprio repository. Quindi tutti quelli che stanno lavorando a un progetto funzionerà solo su quel repository e non dovrà spingere / tirare altro pronti contro termine. Ciò creerà un lavoro più snello, ma lo farà tutti lavorano con almeno 2 repository (risorse condivise e sue progetto), che potrebbe creare confusione.

Sarei felice di sapere se una delle opzioni è una cattiva idea o se c'è un modo migliore.

Grazie!

    
posta roman 04.08.2014 - 09:24
fonte

2 risposte

4

Suggerirei di creare un nuovo repository per ogni progetto. A parte il fatto che è una pratica comune, è anche pratica. Uno dei vantaggi sarebbe che non è necessario recuperare tutti i progetti, quando si vuole lavorare su un singolo progetto. Un secondo vantaggio sarebbe che tutti i file, i rami, i messaggi di registro ecc. Sono applicabili a un singolo progetto, quindi non è necessario scavare attraverso informazioni irrilevanti.

Se un progetto dipende da un altro progetto, è possibile utilizzare la funzionalità del sottomodulo git. Le modifiche apportate al sottomodulo possono essere facilmente trasferite al repository centrale (ad es. GitHub) e tirate dagli altri progetti, in modo tale che ne traggano vantaggio. Ovviamente è anche possibile creare rami per il sottomodulo, nel caso si abbiano modifiche specifiche del progetto. Maggiori informazioni sui sottomoduli in git possono essere trovati qui nella documentazione sul sottomodulo Git .

    
risposta data 04.08.2014 - 10:21
fonte
0

Il mio team ha adottato un approccio diverso al problema delle risorse condivise, ovvero pubblicarlo come pacchetto NuGet e ospitarlo su una condivisione di rete locale. Questo ha il vantaggio che quando si aggiorna la risorsa condivisa con una modifica di rottura, non si interrompono i progetti che dipendono da esso. Un piccolo svantaggio è che richiede molto tempo apportare piccole modifiche (ad esempio aggiungendo un metodo di estensione), ma ritengo che i pro superino gli svantaggi

Puoi trovare ulteriori informazioni su Documenti NuGet .

    
risposta data 04.08.2014 - 10:10
fonte

Leggi altre domande sui tag

Integrazione di un sito Web mobile in un'app mobile Supporto migliore per il controllo delle opzioni di stampa come intestazioni e piè di pagina da Javascript [chiuso]