Qual è la struttura migliore per un repository?

Question

Qual è la struttura migliore per un repository?

#1 da (4 voti)
#2 da (0 voti)

2

Ho esaminato molti repository di software open source e ho trovato alcuni elementi comuni e cose simili che le persone fanno in modo diverso l'una dall'altra.

Ad esempio, ogni repository ha un file README , un file INSTALL , un file COPYING e cose del genere.

Altre cose sono diverse:

Alcuni progetti, come git, hanno il loro codice sorgente nel livello root, mentre altri hanno il codice sorgente in una cartella src/ e altri, come il kernel Linux, hanno il codice sorgente diffuso in diverse cartelle a livello di root, che dividono il codice per aree;
Alcuni hanno i loro test in una cartella t/ , mentre altri in una cartella tests/ , o altrimenti nominati;
Alcuni hanno file sull'invio delle patch e chi sono i manutentori, e quelli potrebbero trovarsi all'interno di qualche Documentation/ o nel livello root.

Ci sono raccomandazioni? Una buona pratica?

Ad esempio: personalmente, non mi piace il codice nel livello root, git-fashion. Sembra disordinato e confonde uno che cerca di iniziare come contributore (specialmente perché hanno del codice all'interno delle cartelle e anche gli script a livello di root, è davvero disordinato).

Se dovessi iniziare un mio progetto e volessi iniziare sin dall'inizio, ci sono dei consigli? Migliori pratiche? Come posso creare una struttura chiara e pulita?

Grazie!

git open-source version-control project-structure

posta jpmelos 25.06.2011 - 02:14

fonte

2 risposte

Leggi altre domande sui tag git open-source version-control project-structure

GPL: termini di licenza Come gestisci le dipendenze cross-class su distruzione / progettazione (più di una domanda C ++)

score 4 · Answer 1

Riservare la root per i bit misc (in modo da avere un posto per directory e file di vario genere che potrebbero essere utili per l'archiviazione nel repository), avviare l'albero dei sorgenti di un livello inferiore. Per ospitare un posto per più componenti, aggiungi un secondo livello per il tuo primo componente.

Se stai usando git puoi sempre rimodellare in seguito, non preoccuparti troppo.

score 0 · Answer 2

Se il tuo repository è una libreria che prevedi di distribuire o distribuire come pacchetto, potrebbe essere necessaria una struttura specifica. Ad esempio, pip ha alcune regole rigide su diversi file e le loro posizioni, che si tradurrebbero in una struttura specifica del tuo repository.

Un framework potrebbe anche dettare alcune regole.

Gli strumenti che usi potrebbero avere aspettative specifiche. Ad esempio, per i progetti creati con Visual Studio, troverai un file .sln nella directory principale e la struttura virtuale della soluzione in Visual Studio non rifletterà necessariamente la struttura fisica dei file. Ad esempio, i progetti possono essere raggruppati nella struttura virtuale dell'IDE, ma essere tutti memorizzati nella directory radice sul disco.

La tua community potrebbe anche avere uno stile specifico. Ad esempio, non è insolito che i progetti C # siano raggruppati in questo modo:

/Project1
/Project1Tests
/Project2
/Project2Tests

invece di avere una directory /src e una /tests . Sembra che tu stia usando una lingua dove /t è comune; Non ho mai visto alcun repository che abbia una directory /t in esso.

Infine, gli strumenti relativi al controllo della versione possono anche avere i loro vincoli. Ad esempio, se usi GitHub, avere una README.md sarebbe una buona idea, perché GitHub mostrerà automaticamente la documentazione all'interno di questo file.

Una volta raccolte le regole di:

Il gestore pacchetti,
Il framework,
L'IDE,
La comunità,
L'ecosistema di controllo della versione,

dovresti avere una visione chiara delle regole da applicare. In dubbio, controlla i repository open source per la tua lingua / tecnologia di scelta e copia la loro struttura.