Gdybym zrobił analogię z hostingiem serwera WWW, powiedziałbym, że dane gita powinny być w /var/gitśrodku, więc moje repozytorium gita powinno być/var/git/myrepo
P : Czy to słuszne przypuszczenie?
Gdybym zrobił analogię z hostingiem serwera WWW, powiedziałbym, że dane gita powinny być w /var/gitśrodku, więc moje repozytorium gita powinno być/var/git/myrepo
P : Czy to słuszne przypuszczenie?
Odpowiedzi:
Nie ma tu żadnej dobrej ani złej odpowiedzi, z wyjątkiem tej podyktowanej przez twoją osobistą religię i zawartość strony hier(7)podręcznika w twoim systemie.
typowy Linux hierpodręcznika ; Typowy BSD hierpodręcznika )
/var/git/*osobiście wydaje mi się rozsądny. Tam trzymam moje.
Umieść go w katalogu (lub udostępnionym systemie plików) w /srv. Po to jest.
/srvKatalog jest przeznaczony dla danych site-specific obsługiwanych przez system . Od standardu:
Głównym celem określenia tego jest, aby użytkownicy mogli znaleźć lokalizację plików danych dla konkretnej usługi, a także aby usługi wymagające pojedynczego drzewa dla danych tylko do odczytu, danych zapisywalnych i skryptów (takich jak skrypty cgi) mogły być rozsądnie umieszczone. Dane, które są interesujące tylko dla konkretnego użytkownika, powinny znaleźć się w katalogu osobistym tego użytkownika.
Metodologia stosowana do nazewnictwa podkatalogów
/srvjest nieokreślona, ponieważ obecnie nie ma zgody co do tego, jak należy to zrobić. Jedną z metod strukturyzacji danych/srvjest protokół, np.ftp,rsync,www, Icvs. W dużych systemach może on być przydatny do struktury/srvprzez kontekście administracyjnym, takie jak/srv/physics/www,/srv/compsci/cvsitp Taka konfiguracja będzie się różnić od hosta do hosta. Dlatego żaden program nie powinien polegać na określonej strukturze podkatalogów/srvistniejących lub danych koniecznie przechowywanych/srv. Jednak/srvzawsze powinien istnieć w systemach zgodnych z FHS i powinien być używany jako domyślna lokalizacja takich danych.Dystrybucje muszą uważać, aby nie usuwać lokalnie umieszczonych plików w tych katalogach bez zgody administratora.
W systemie obsługującym SELinux domyślnym katalogiem jest /var/www/git, a repozytoria powinny znajdować się w jego podkatalogach. Możesz też użyć np. /srv/gitUstawić kontekst pliku na równoważny:
semanage fcontext -a -e /var/www/git /srv/git
/home/git/
Na początku może się to wydawać niekonwencjonalne, ale jest to bardzo rozsądne, ponieważ ten katalog jest tworzony dla ciebie (z odpowiednimi uprawnieniami) sudo useradd git. Możesz po prostu przełączyć się na użytkownika git cdi natychmiast uruchomić:
$ mkdir .ssh; chmod 700 .ssh
$ touch .ssh/authorized_keys; chmod 600 .ssh/authorized_keys
i umieść klucze publiczne swoich rówieśników w właśnie utworzonym pliku autoryzowanych_kluczy.
Po git init --baretwoim projekcie „adres URL” jest po prostu… poczekaj na niego…
git@<server>:<project>
Jak powiedział voretaq7, nie ma właściwej lub złej odpowiedzi na taki temat. Jeśli jednak chcesz śledzić oprogramowanie, wygląda na to, że oprogramowanie baz danych przechowuje swoje dane
/var/lib/soft
Na przykład dla Postgresql 9.1 na debianie jest to folder
/var/lib/postgresql/9.1/
Więc osobiście wybrałbym
/var/lib/git
W moim Arch Linux mam /srv/httpapache (który jest domyślny dla systemu) i używam go również dla serwerów http node.js. Podobnie postanowiłem po prostu umieścić wszystkie repozytoria git /srv/git.
Używam GitLab i /srv/gitjest to folder domowy git również w tym przypadku.
Ostatecznie to zależy od ciebie. Odkryłem, że trzymanie się formatu podobnego do innych usług w twojej dystrybucji jest łatwe do zapamiętania.
Jeśli używasz jakiegoś frontendu do git, po prostu idź tam, gdzie chce go umieścić pakiet z twojej dystrybucji. Wszystko inne tworzy niepotrzebne niezgodności.
Po pierwsze, jeśli chodzi o sugestię użycia / srv, zakłada się, że wszystkie repozytoria git są używane na stronach internetowych. To może być prawda dla ciebie, ale możesz mieć oprogramowanie, które nie jest stroną internetową.
Po drugie, przechowując repozytoria kodu poza / var / www / html lub / srv / html, zyskujesz dwie fajne korzyści. Możesz tworzyć dowiązania symboliczne do swojego repozytorium na dowolnym poziomie, co ułatwia ukrywanie bibliotek. Ponadto, jeśli lokalizacja repozytorium w ogóle się zmieni, nie musisz modyfikować konfiguracji hosta wirtualnego. Zamiast tego po prostu dostosowujesz swoje dowiązania symboliczne.
Używałem / var / repo, ale myślę, że / var / git jest lepszy i od tej pory będę go używać.