Come decidere la divisione repo git con considerazioni sul flusso di lavoro?

Question

Come decidere la divisione repo git con considerazioni sul flusso di lavoro?

#1 da (1 voti)

1

Stiamo passando da sovversione a git per motivi di sviluppo ramificato e distribuito. Uno dei problemi in passato con il nostro vecchio flusso di lavoro del repository era che ogni applicazione aveva il proprio repository. Un'enorme applicazione aveva il suo repository e una piccola applicazione che aveva 15 file e quasi mai cambiata aveva il suo. La maggior parte delle applicazioni sono interdipendenti almeno sul lato db, se non condividono il codice, come parte della nostra suite di prodotti complessiva. Ci sono solo un paio di applicazioni primarie, ma stanno diventando sempre più integrate e potrebbero presto usare la stessa API per tutte le loro richieste di "back-end".

Quando avrò una proposta su come andare avanti usando git, organizzazione repo e flusso di lavoro, sto cercando di decidere tra alcune scelte ...

monolitico: un repository principale (1 repository)
indipendente: un repository separato per quasi tutte le applicazioni / librerie (totale ~ 20) più il repository principale con i sottomoduli
compromesso: un repository per applicazione principale, uno per tutte le app minori e uno per le librerie (~ 4 repos) più il repository principale con i sottomoduli

Inizialmente ho iniziato con l'approccio monolitico con il workflow git e mi sono sentito a mio agio con quell'approccio, ma più leggo vedo che questa non è la migliore pratica per git. Sto valutando l'approccio separato per i repository e i sottomoduli, tuttavia aggiunge molti passaggi al flusso di lavoro non direttamente supportato nei sistemi di repository (es: richiamo richieste in più repository) e sembra essere soggetto a problemi nel repository principale se non si presta attenzione all'ordine di operazioni.

Sto iniziando a orientarmi verso l'approccio di compromesso, tuttavia il fatto che abbia effettuato alcuni test con l'approccio monolitico e non riscontrando alcun problema mi fa pensare che nel tentativo di seguire le best practice effettivamente realizzerò il nostro flusso di lavoro più complesso, richiede più tempo per gestire pull e release e più incline agli errori.

Sto capendo in modo errato la migliore pratica di "un repository per progetto"? La nostra base di codice delle applicazioni correlate dovrebbe essere considerata un progetto quindi un repository?

Pensieri?

git

posta Dan Roberts 11.08.2015 - 15:53

fonte

1 risposta

Leggi altre domande sui tag git

L'implementazione di python's calendar.month_name di una stringa vuota nel primo indice è una buona pratica o un design scadente? Porting di sicurezza da Java / .NET a PHP

score 1 · Answer 1

La maggior parte del tempo, se pensi di aver bisogno di sottomoduli per mantenere sincronizzate le versioni dipendenti tra i tuoi repository separati, è un segno che starai meglio con un singolo repository. I repository separati dovrebbero di solito essere altamente indipendenti e poter essere aggiornati e rilasciati senza preoccuparsi delle versioni di altri progetti.

Anche con tutti i progetti in un repository logico, la natura distribuita di git significa che puoi ancora usare repository fisici separati se questo ha senso per la tua organizzazione. Ad esempio, il kernel di Linux ha un grande repository logico, dove alla fine tutto viene unito, ma i vari sottosistemi hanno i loro repository fisici separati in cui viene eseguito il lavoro quotidiano.

I sottomoduli sono principalmente destinati a situazioni in cui si ha una strong dipendenza dal codice di terze parti che non ha dipendenza reciproca. Ad esempio, se la tua applicazione dipendesse in larga misura da versioni specifiche di bleeding di una libreria ampiamente utilizzata come numpy , a cui contribuisci regolarmente patch, ma altrimenti non sanno che la tua applicazione esiste.