Где обычное место для хранения git-репозиториев в дереве файловой системы linux?


58

Если я проведу аналогию с хостингом веб-сервера, я бы сказал, что данные git должны быть в нем /var/git, поэтому мой репозиторий git будет в/var/git/myrepo

Q : Это правильное предположение?

Ответы:


31

Здесь нет правильного или неправильного ответа, кроме того, который продиктован вашей личной религией и содержанием hier(7)справочной страницы в вашей системе.

типичная hierсправочная страница Linux ; типичная hierстраница BSD )

/var/git/*кажется разумным лично мне. Вот где я храню свои.


3
Точно так же в Arch Linux в папке Apache находится / srv / http (вместо / var / www, как и в некоторых других дистрибутивах), поэтому я поместил свой git в / srv / git.
trusktr

Где-то в / var / это кажется разумным, но смотрите также ответ Дениса Р. ниже: serverfault.com/a/433584/45819 - он помещает его в / var / lib / git по веским причинам
с

30

Поместите его в каталог (или общую файловую систему) в /srv. Вот для чего это.

/srvСправочник предназначен для сайтов-специфических данных , обслуживаемых системой . Из стандарта:

Эта основная цель определения этого заключается в том, чтобы пользователи могли находить местоположение файлов данных для конкретной службы, и чтобы разумно размещать службы, которым требуется единственное дерево для данных только для чтения, записываемых данных и сценариев (таких как сценарии cgi). Данные, представляющие интерес только для конкретного пользователя, должны помещаться в домашний каталог этих пользователей.

Методология, используемая для именования подкаталогов, /srvне определена, поскольку в настоящее время нет единого мнения о том, как это должно быть сделано. Одним из способов структурирования данных /srvявляется протокол, например. ftp, rsync, www, И cvs. На больших системах это может быть полезно структурировать /srvадминистративным контексте, например /srv/physics/www, /srv/compsci/cvsи т.д. Эта установка будет отличаться от хоста к хосту. Поэтому ни одна программа не должна полагаться на конкретную структуру подкаталога из /srvсуществующих или данные, которые обязательно хранятся в /srv. Однако /srvвсегда должен существовать в системах, соответствующих FHS, и должен использоваться в качестве местоположения по умолчанию для таких данных.

Распространители должны позаботиться о том, чтобы не удалять локально размещенные файлы в этих каталогах без разрешения администратора.


В системе с поддержкой SELinux каталог по умолчанию - это каталог /var/www/git, а репозитории должны находиться в его подкаталогах. Или вы можете использовать, например, /srv/gitи установить контекст файла равным:

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

5
/home/git/

Поначалу это может показаться немного необычным, но это очень разумно, поскольку этот каталог создан для вас (с правильными разрешениями), когда вы это делаете sudo useradd git. Вы можете просто переключиться на пользователя git cdи сразу запустить:

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

и поместите открытые ключи ваших пиров в только что созданный файл author_keys.

После того, как git init --bareваш проект, URL-адрес просто ... ждать его ...

git@<server>:<project>

Почти как рекомендуется в книге "Pro Git": git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-the-Server
exic

1

Как сказал voretaq7, нет правильного или неправильного ответа на эту тему. Однако, если вы хотите следовать за софтами, кажется, что софты базы данных хранят свои данные в

/var/lib/soft

Например, для Postgresql 9.1 в Debian папка

/var/lib/postgresql/9.1/

Так что я бы лично выбрал

/var/lib/git

1

Это полностью зависит от вас. Оптимально, однако, вы должны поместить каталог git data в отдельный раздел или даже диск, чтобы упростить обновление системы и т. Д. И, конечно, вы должны убедиться, что на диске достаточно свободного места.


1

В моем Arch Linux у меня есть /srv/httpapache (который является системным по умолчанию), и я использую его также для моих http-серверов node.js. Точно так же я решил просто поместить все репозитории git /srv/git.

Я использую GitLab, и /srv/gitв этом случае я тоже являюсь домашней папкой для git.

В конечном счете, это зависит от вас. Я обнаружил, что придерживаться формата, аналогичного другим сервисам в вашем дистрибутиве, легко запомнить.


0

Если вы используете какой-то внешний интерфейс для git, просто переходите туда, где его хочет разместить тот, который поставляется вашим дистрибутивом. Все остальное просто создает ненужные несовместимости.


1 / Я не использую внешний интерфейс для git 2 / Git не поставляется с рекомендацией о том, где размещать git-репозитории ... любая папка, в которой вы выполняете git init, является git-репозиторием.
Сэмюэль Россиль

1 / В качестве внешнего интерфейса я бы предположил, что git-сервер обслуживает репо. 2 / любой такой сервер, даже если используется только HTTP-сервер, будет иметь местоположение по умолчанию. Конечно, мы говорим о месте для хостинга, когда вы работаете с кодом, .git в основном находится внутри проекта.
hultqvist

0

Во-первых, что касается предложения использовать / srv, вы предполагаете, что все git-репозитории используются для веб-сайтов. Это может быть правдой для вас, но у вас может быть программное обеспечение, которое не является веб-сайтом.

Во-вторых, храня свои репозитории кода вне / var / www / html или / srv / html, вы получаете два приятных преимущества. Вы можете создавать символические ссылки в своем репо на любом уровне, что облегчает скрытие ваших библиотек. Кроме того, если местоположение вашего репозитория вообще меняется, вам не нужно изменять конфигурации вашего виртуального хоста. Вместо этого вы просто настраиваете свои символические ссылки.

Я использовал / var / repo, но я думаю, что / var / git лучше, и теперь буду использовать это.


0

Когда я загружаю git-репозитории, чтобы поддерживать конфигурации сайта, которые я затем развертываю, я сохраняю их в

/ Данные / РЕПО / $ REPO_GROUP_OR_USER / $ REPO_NAME

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.