Dov'è il posto convenzionale per archiviare i repository git in un albero di file system linux?


58

Se faccio un'analogia con l'hosting di un server Web, direi che i dati di git dovrebbero essere presenti /var/git, quindi il mio repository git sarebbe in/var/git/myrepo

D : È la supposizione giusta?

Risposte:


31

Non esiste una risposta giusta o sbagliata qui, tranne quella dettata dalla propria religione personale e dai contenuti della hier(7)manpage sul proprio sistema.

tipica hiermanpage Linux ; tipica hiermanpage BSD )

/var/git/*mi sembra ragionevole personalmente. Ecco dove tengo il mio.


3
Allo stesso modo, nella cartella di Arch Linux apache è / srv / http (invece di / var / www come alcune altre distro), quindi ho inserito le mie cose git in / srv / git.
trusktr,

Da qualche parte sotto / var / sembra ragionevole, ma vedi anche la risposta di Denis R di seguito: serverfault.com/a/433584/45819 - la inserisce in / var / lib / git con buone ragioni
mit

30

Inseriscilo in una directory (o filesystem condiviso) sotto /srv. Questo è quello che serve.

La /srvdirectory è destinata ai dati specifici del sito forniti dal sistema . Dallo standard:

Questo scopo principale di specificare ciò è che gli utenti possano trovare la posizione dei file di dati per un particolare servizio e che i servizi che richiedono un singolo albero per dati di sola lettura, dati scrivibili e script (come gli script cgi) possano essere ragionevolmente posizionati. I dati che interessano solo un utente specifico dovrebbero andare nella home directory di quell'utente.

La metodologia utilizzata per nominare le sottodirectory di /srvnon è specificata in quanto attualmente non vi è consenso su come farlo. Un metodo per strutturare i dati /srvè tramite protocollo, ad es. ftp, rsync, www, E cvs. Nei sistemi grandi può essere utile per strutturare /srvdal contesto amministrativo, come /srv/physics/www, /srv/compsci/cvsecc Questa configurazione varierà da host a host. Pertanto, nessun programma dovrebbe fare affidamento su una specifica struttura di sottodirectory di /srvdati esistenti o in cui sono necessariamente memorizzati /srv. Tuttavia, /srvdovrebbe sempre esistere su sistemi conformi a FHS e dovrebbe essere utilizzato come posizione predefinita per tali dati.

Le distribuzioni devono fare attenzione a non rimuovere i file collocati localmente in queste directory senza l'autorizzazione dell'amministratore.


Su un sistema abilitato per SELinux, la directory predefinita è /var/www/gite i repository dovrebbero trovarsi nelle sue sottodirectory. In alternativa, è possibile utilizzare, ad esempio, /srv/gite impostare il contesto del file come equivalente:

semanage fcontext -a -e /var/www/git /srv/git

5
/home/git/

All'inizio questo potrebbe sembrare un po 'non convenzionale, ma è molto ragionevole poiché questa directory è fatta per te (con le autorizzazioni corrette) quando lo fai sudo useradd git. Puoi semplicemente passare all'utente git cded eseguire immediatamente:

$ mkdir .ssh; chmod 700 .ssh
$ touch .ssh/authorized_keys; chmod 600 .ssh/authorized_keys

e inserisci le chiavi pubbliche dei tuoi colleghi nel file autorizzato_keys appena creato.

Dopo il git init --baretuo progetto, l'URL è solo ... aspetta ...

git@<server>:<project>

Quasi come raccomandato nel libro "Pro Git": git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-the-Server
exic

1

Come diceva voretaq7, non esiste una risposta giusta o sbagliata su tale argomento. Tuttavia, se si desidera seguire i softs, sembra che i softs del database memorizzino i loro dati

/var/lib/soft

Ad esempio, per Postgresql 9.1 su debian la cartella è

/var/lib/postgresql/9.1/

Quindi sceglierei personalmente

/var/lib/git

1

Dipende interamente da te. In modo ottimale, tuttavia, dovresti mettere la directory dei dati git su una partizione separata o persino su un disco per facilitare gli aggiornamenti del sistema ecc. E, naturalmente, devi assicurarti che ci sia abbastanza spazio su disco disponibile.


1

Sul mio Arch Linux ho /srv/httpper apache (che è l'impostazione predefinita del sistema) e lo uso anche per i miei server http node.js. Allo stesso modo ho deciso di inserire tutti i repository git /srv/git.

Uso GitLab ed /srv/gitè anche la cartella home di git in quel caso.

Alla fine, dipende da te. Ho scoperto che attenersi a un formato simile ad altri servizi nella tua distribuzione è facile da ricordare.


0

Se usi un frontend per git, vai semplicemente dove quello impacchettato dalla tua distribuzione vuole posizionarli. Nient'altro sta solo creando incompatibilità inutili.


1 / Non sto usando un frontend per git 2 / Git non ha una raccomandazione su dove posizionare i repository git ... qualsiasi cartella in cui si esegue git init è un repository git.
Samuel Rossille

1 / Per front end, suppongo che il server git serva i repository. 2 / qualsiasi server di questo tipo, anche se viene utilizzato solo un server HTTP, avrà una posizione predefinita. Naturalmente stiamo parlando della posizione per l'hosting, quando lavori con il codice, il .git è principalmente all'interno del progetto.
hultqvist,

0

Innanzitutto, per quanto riguarda il suggerimento di utilizzare / srv, si presume che tutti i repository git siano utilizzati per i siti Web. Potrebbe essere vero per te, ma potresti avere un software che non è un sito web.

In secondo luogo, memorizzando i repository di codice al di fuori di / var / www / html o / srv / html, si ottengono due vantaggi. È possibile creare collegamenti simbolici nel repository a qualsiasi livello, rendendo più semplice nascondere le librerie. Inoltre, se la posizione del repository cambia, non è necessario modificare le configurazioni dell'host virtuale. Invece devi solo regolare i tuoi collegamenti simbolici.

Stavo usando / var / repo, ma penso che / var / git sia migliore e lo userò d'ora in poi.


0

Quando sto scaricando repository git al fine di mantenere le configurazioni del sito in cui poi dispongo, le memorizzo

/ Dati / repos / $ REPO_GROUP_OR_USER / $ REPO_NAME

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.